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PREFACE 



This manual defines the interface between the standard, 
Communications Control Program (CCP), version 3.1, and 
a terminal interface program (TIP). The TIP Writer's 
Guide is intended for systems analysts and designers who 
plan to write programs supporting; 

• A terminal which uses a protocol not currently 
handled by standard CCP 

• A terminal which uses a variation of one of the 
standard protocols supported by CCP 



It is assumed that the 
functions as described in 
with TIP functions as 
Programmer's Reference 
that the TIP writer is 
version of the PASCAL 
the state programming 
manuals listed below. 



reader is familiar with CCP 
the CCP Reference Manual, and 
described in the CCP System 

Manual. It is further assumed 
familiar with the CCP CROSS 
programming language, and with 

language as described in the 



The TIP writer should also be familiar with host products 
that directly affect the operation of a TIP: the Network 
Access Method (NAM) and the Network Definition 
Language (NDL). Knowledge of the host's Interactive 
Facility (lAF), Remote Batch Facility (RBF), and 
Transaction Facility (TAF) may also be helpful, depending 
on the type of terminal to be added to the network. 

When interfacing a new TIP to the system, the TIP writer 
must use only the structures and functions described in 
this document. Control Data cannot be responsible for 
the functioning of any system with TIPs which use any 
interfaces not described in this manual. Further, when 
adding new CCP features or corrective code, Control 
Data can change without notice any TlP-related structure 
or function not described in this manual. 



CONVENTIONS USED 

Throughout this manual, the following conventions are 
used in the presentation of statement formats, operator 
type-ins, and diagnostic messages: 



ALN 



aln 



[] 



Uppercase letters indicate words, acronyms, 
or mnemonics either required by the network 
software as input to it, or produced as output. 

Lowercase letters identify variables for 
which values are supplied by the NAM or 
terminal user, or by the network software as 
output. 

Ellipses indicate that the omitted entities 
repeat the form and function of the entity 
last given. 

Square brackets enclose entities that are 
optional; if omission of any entity causes the 
use of a default entity, the default is 
underlined. 

Braces enclose entities from which one must 
be chosen. 



Unless otherwise specified, all references to numbers are 
to decimal values; all references to bytes are to 8-bit 
bytes; all references to characters are to 8-bit, 
ASCII-coded characters. 



RELATED MANUALS 

The manuals listed below contain additional information 
on software elements of the Control Data Computer 
Systems and software used in network operations. These 
manuals can be obtained from CDC Literature and 
Distribution Services, 308 North Dale Street, St. Paul, 
Minnesota 55103. 



Publication Title 



Publication Number 



Network Products 
NOS 1 Operator's Guide 

NOS 1 Reference Manual 
Volumes 1 and 2 



60435600 

60445300 
60445400 



Network Products 
Interactive Facility, Version 1 
Reference Manual 



60455250 



Network Products 
Transaction Facility, Version 1 
Reference Manual 



60455340 



CYBER Cross System, Version 1 
Build Utilities Reference Manual 



60471200 
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Network Products 

Communications Control Program (CCP) 

Version 3 

Reference Manual 60471400 

State Programming Language Reference Manual 60472200 

Network Products 

Communications Control Program, Version 3 

System Programmer's Reference Manual 60474500 



Network Products 

Network Definition Language (NDL) 

Reference Manual 



60480000 



Network Products 

Network Access Method (NAM), Version 1 

Reference Manual 



60499500 



Network Products 

Remote Batch Facility, Version 1 

Reference Manual 



60499600 



CCP Support Software 1 
Reference Manual 



96836000 



CYBER Cross System, Version 1 
PASCAL Computer Reference Manual 



96836100 



CYBER Cross System, Version 1 
Macro Assembler Reference Manual 



96836500 



This product is intended for use only as described in 
this document. Control Data cannot be responsible 
for the proper functioning of underscribed features 
or undefined parameters. 
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TIP WRITING OVERVIEW 



A Terminal Interface Package (TIP) is responsible for 
converting messages between the terminal format and the 
virtual terminal format used by application programs in 
the host. When a terminal logs onto the network, it 
becomes connected to an application program in the host, 
and a message transfer session begins. The multiplex 
subsystem of CCP is responsible for making the physical 
characteristics of the line transparent to the TIP; that is, 
the TIP need only concern itself with the characteristics 
of the terminal. The TIP then makes the physical char- 
acteristics of the terminal transparent to the application 
program in the host, so that the host programs need only 
concern themselves with the characteristic of a virtual 
terminal. Two types of virtual terminals are provided: an 
interactive type for console devices, and a batch type for 
all non-console devices. Note that a TIP can also provide 
a transparent mode (no conversion to or from virtual 
terminal characteristics). 



REQUIRED INFORMATION 

This manual concerns itself only with the characteristics 
of a TIP. It is assumed that the reader is familiar with 
PASCAL language, with the state programming language, 
and with the functional characteristics of a network pro- 
cessing unit (NPU), as set forth in the CCP 3 Reference 
Manual. Section 2 of this manual lists the materials which 
are desirable to have on hand when writing a TIP. 

COMMON SUPPORT FUNCTIONS 
PROVIDED FOR ALL TIPS 

CCP provides five support functions that are needed by 
every TIP: a Service Module (SVM), a Block Protocol 
Interface Package (BIP), a set of base system subroutines, 
a text processor, and a multiplex subsystem. The func- 
tions provided by each of these interfaces are as follows: 

• SERVICE MODULE: This handles all the terminal 
operational characteristics and status information 
that is to be exchanged with the host. SVM also 
provides table construction and initialization, and 
handles any special messages which the TIP may 
need to send to the host. 

• BLOCK PROTOCOL INTERFACE PACKAGE 
(BIP): This provides for transportation of data 
from a host application to the TIP. BIP also 
provides block flow control for the TIP. 



■ BASE SYSTEM: The base consists of a monitor 
which controls task allocation within the NPU and 
a set of standard subroutines which may be used 
by a TIP writer. TIPs use standard base sub- 
routines for buffer management and for timing 
message-related events. 

■ MULTIPLEX SUBSYSTEM: The multiplex subsys- 
tem provides various functions to transfer data 
between the NPU and the terminal. It isolates the 
TIP from line characteristics and performs the 
common functions for controlling the line 
hardware. The multiplex subsystem consists of 
both software and hardware. Multiplex hardware 
consists of a Multiplex Line Interface Adapter 
(MLIA) and the Communication Line Adapters 
(CLAs). The software consists of a PASCAL 
language portion which interfaces with the TIP 
(this is called the command driver), and a micro- 
code portion which controls the input and output 
of characters (collectively this is called the 
multiplex firmware; individually it is called the 
input processor and the output processor). The 
multiplex firmware interfaces to the TIP's own 
input state programs (these are written in state 
programming language) which aid in translating 
incoming characters and formatting the incoming 
message. 

• TEXT PROCESSING: Two interfaces are neces- 
sary: the first is between the PASCAL coded 
portions of the TIP and the common text pro- 
cessing programs (called the text processor); the 
second is between the text processor and the TIP's 
own text processing programs (written in state 
programming language). 

In general, text processing programs are written to con- 
vert text and format (on a character-by-character basis) 
for downline messages, while input state programs are 
written to do the same thing for upline messages. Input 
state programs also assist in demultiplexing the upline 
messages which the multiplex sttisystem multiplexed as 
they entered the NPU. 

The five interfaces for the TIP are shown in figure 1-1. 
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Figure 1-1. Principal Interfaces for a TIP 



TIP WRITER'S TASKS 



Since a standard Host Interface Package (HIP) is supplied 
in every local NPU, the TIP writer need not concern him- 
self with actually transmitting or receiving data across 
the coupler interface to the host. Similarly, since a 
standard Link Interface Package (LIP) is supplied in every 
remote NPU and in every NPU connected to a remote 
NPU, the TIP writer need not concern himself whether his 
TIP executes in a local or in a remote NPU. The TIP 
writer must, however, provide the following: 

• Modification to system table structures for TIP- 
defined fields within common tables. 

• Link editor code to initialize line and terminal 
data structures which are unique to the TIP. 

• PASCAL code to handle requests from the host to 
change the status of lines or terminals, and to 
inform the host that the requested changes were 
or were not made. 

■ PASCAL code to support the IVT interface for 
console devices and the BVT interface for non- 
console devices. Code to support transparent 
transmissions for consoles is optional. 

• PASCAL code to support all the protocol re- 
quirements of the terminal. Error processing 
must be supplied to handle protocol and other 
message processing failures. 

■ State programming language programs to handle 
the protocol requirements and data translation of 
upline (incoming) messages. 

• State programming language programs to handle 
the protocol requirements and data translation of 
downline (outgoing) messages. 



The TIP consists of five component modules as shown in 
figure 1-2. These modules execute on four priority levels, 
as will be discussed later. The component modules are as 
follows: 

■ The first module initializes the Terminal Control 
Block (TCB) for each terminal serviced (OPS-level 
initialization). This module is called by the ser- 
vice module to complete the initialization of the 
dynamic data structure which controls message 
transfers with a terminal. This module must ini- 
tialize any TCB fields which the TIP uses as it 
starts processing a message. The OPS-level TIP 
can change TCB fields as needed during processing. 

• The second module handles special priority calls 
from the multiplexer subsystem (Mux 2 level TIP). 

• The third module contains the bulk of the higher 
level decision logic (OPS-level TIP). The OPS- 
level TIP provides overall control of every ter- 
minal which uses this protocol. It also provides 
downline code translation and protocol control 
functions (text processing is called from the OPS 
level). 

• The fourth module handles input message pro- 
cessing, character-by-character (input state pro- 
grams). A single set of input state programs is 
used for all terminals under the TIP's control. 

• The fifth module handles output message pro- 
cessing, character-by-character (text processing 
state programs). The OPS-level TIP calls these 
programs when the TIP has a full block of data 
ready to be converted. Text processing state 
programs are processed on the OPS-level, but are 
interrupted by the multiplexer subsystem firm- 
ware. These programs are not reentrant. 



1-2 
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Figure 1-2. TIP Modules 



These five modules execute at four priority levels. 
Priority levels are system defined; the TIP w/riter can 
exercise no control over them. The levels are listed in 
precedence order, with the highest given first: 

• Interrupt level 1 for processing output characters 
to the terminals 

■ Interrupt level 2 for processing input characters 
from the terminals 

• Mux-2 level for priority processing of certain ter- 
minal events. This level might be used to main- 
tain high line utilization, or to provide a high 
priority response to a terminal input. 

• OPS level. This is the lowest NPU processing 
level. The base system monitor gives control to 
the OPS-level TIP to perform a single task. The 
TIP must return control to the monitor when this 
task is completed or suspended. The monitor 
assigns control of the NPU by calling all OPS level 
modules in rotational order from a list. For 
example, the service module can request the TIP 
to perform a task by placing the request (in the 
form of a work list entry or WLE) in the TIP's 
queue of tasks to be performed. Eventually, the 
monitor will give control to the TIP to perform 
the required task. 

NOTE 

Any mixing of routines between the Mux-2 
level and the OPS-level requires reentrant 
code at both levels. 



In summary, the TIP writer has four main tasks, listed as 
follows: 

• Writing modifications to the system data struc- 
tures. 

■ Writing TIP programs and subprograms in PASCAL 
language to perform all of the non-character 
processing functions of the TIP, including error 
processing. 

• Writing state language programs to convert the 
code, and to format input and output messages, 
character-by -character. 

• Writing link edit directives to initialize the sys- 
tem data structures during the CCP build process. 

SUMMARY OF DOWNLINE 
MESSAGE PROCESSING 

After the connection to a terminal has been established, a 
downline message can be processed. Figure 1-3 sum- 
marizes the process. 

The HIP or LIP handles the initial step of assembling the 
message block (MSG or BLK type of block) into buffers in 
the NPU. The TIP is not involved in this stage of pro- 
cessing. 

Once the HIP or LIP acknowledges that the block has been 
successfully received, that module sends a worklist to the 
BIP to queue the block to the appropriate TCB. The BIP 
adds the data block to the TCB's queue and generates a 
worklist for the TIP. When the TIP gains control with this 
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NOTES TO FIGURE 1-3: 

1. A block of downline message is transmitted to the HIP (local NPU) or LIP (remote NPU). That module 
assigns buffers to receive the block of data. 

2. The HIP or LIP generates a WLE to the BIP for routing block to the TIP. 

3. The BIP queues the block to the TCB, and generates a WLE to the TIP. 

4. The TIP calls the test processor interface (PTTPINF), after setting up the TPCB with information to 
control the conversion. TPCB fields are the only means of communication between the TIP's OPS level and 
the text processor. 

5. The text processor uses the TIP's text processing state programs to govern transfer and conversion of the 
data. Characters are taken from the source buffers, processed, and placed in the destination buffers. 
Both code and format conversion take place at this time. At the end of text processing, control returns 
to the OPS level TIP. The block is ready to be sent to the multiplex subsystem. The TIP releases 
unneeded source buffers. 

6. A TIP calls the command driver (PBCOIN) directly to deliver the message. Transfer parameters are in a 
command packet (NKINCOM). The Multiplex Line Control Block (MLCB) fields are used to control the command 
driver and the multiplex firmware while the message is being transmitted. 

7. The multiplex subsystem transmits the message one character at a time, using firmware and hardware. The 
OPS level TIP is not involved. 

8. After the message is transmitted, the command driver calls the Mux-2 level TIP. The TIP releases buffers, 
and informs the BIP of a successful message transfer. 

9. The BIP creates an acknowledgment message for the host application program. 

Figure 1-3. Simplified Downline Message Flow 



worklist, the TIP checks the data block's validity and 
generates a Text Processing Control Block (TPCB). Then 
the TIP makes a direct call to the text processor interface 
(PTTPINF). This is the interface to the text processor and 
the TIP'S own text processing state programs. State 
programs (input, output, and modem) are described in 
detail in the State Programming Language Reference 
Manual. If the user is not familiar with such state 
programming concepts as state instructions, state pro- 
cesses, state programs, and state program pointer tables, 
he is urged to review these concepts. 



User-written text processing state programs implement 
the character-by-character transfer from the source 
buffer to the newly assigned destination buffer. During 
this transfer, code conversion (if any) occurs, and the 
message is reformatted from IVT/BVT format to terminal 
format. All parameters needed to perform the text 
processing (buffer addresses, flags, counters, control 
fields) are contained in the TPCB. As it converts the 
message, the text processor changes TPCB fields. This 
information will be used by the TIP, when it regains 
control, to find the status of the text processing operation. 
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The TIP does not regain control until the entire block is 
text processed, or until the text processor can do no 
nnore. The TIP releases any source buffers which are no 
longer needed. In many cases, the source data is not 
completely translated. The TIP determines where pro- 
cessing may resume in the source buffer and releases 
those buffers which have been fully processed. 

When the block is fully translated, the message in the 
destination output buffer is ready to be transmitted to the 
terminal via the multiplex subsystem. The TIP makes a 
direct call to the command driver (PBCOIN) and places 
the parameters for the message transmission in a com- 
mand packet (NKINCOM). This ends the TIP's concern 
with the output operation until the command driver 
returns a worklist informing the TIP either that the 
message has been transmitted or that the transmission 
failed. 

The multiplex subsystem sends the block, character by 
character, to the terminal. Output processor firmware 
frames the data character prior to placing it on the 
multiplex output loop. A character is placed on the loop 
in response to an output data demand (ODD) interrupt 
generated by the communication line adapter for that line. 

In the event that the multiplex subsystem cannot send the 
message, the subsystem informs the TIP of the failure, 
and the reason for the failure. Depending on the way the 
TIP is written, the TIP may react as follows: 

• It may choose to try sending the message again 
without notifying the host that a problem exists. 

■ It may mark the terminal or line inoperative, 
release the message, and notify the host that (1) 
the device status has changed to inoperative, and 
(2) the message was not delivered. 

SUMMARY OF UPLINE 
MESSAGE PROCESSING 

Several steps are required to prepare the multiplex 
subsystem for receiving a message (see figure 1-4). As in 
the downline case, the HIP or LIP performs the transfer to 
the host or to the local NPU. The TIP determines if input 
is permitted at this time (input regulation) by calling a 
base subroutine, PTREGL, directly. If reception is per- 
mitted, the TIP calls the command driver to set up the 
input transfer. For asynchronous protocols, PTREGL is 
used to discard input since input is not solicited from 
those terminals. 



Data from the line is placed on the input multiplex loop by 
the CLA. As the multiplex subsystem picks the character 
from the line, it adds framing information consisting of a 
line address. The multiplex subsystem also picks up a line 
status word (if any is available from the CLA), and places 
the entire packet (frame and data) into the circular input 
buffer (CI8). This ends the multiplexing operation. 

The multiplex subsystem attempts to demultiplex the data 
as fast as it is written into the circular input buffer. 
Demultiplexing is activated by a hardware-generated in- 
terrupt that occurs each time a new frame is placed in the 
circular input buffer. 

Demultiplexing control information is contained in the 
modem state programs and the TIP's own input state 
programs. Note that the modem state programs are a set 
of common state programs on the firmware level; the TIP 
writer needs only write the input state programs. 

If status information is detected in the frame, a modem 
state program is called to process it. After the current 
modem state program finishes processing the status, con- 
trol passes to the current input state program. This state 
program controls the conversion of the character and its 
movement into the line-oriented input buffer. Note that 
the firmware is responsible for supplying chained input 
buffers for the data. 

Demultiplexing continues until the end of the block is 
reached. At that time the input state program notifies 
the TIP of this condition with a worklist. The TIP then 
routes the processed block to the host through the BIP. 



UPLINE TEXT PROCESSING 



In some cases it is not possible to convert incoming data 
in a single real time pass as the characters are being 
received from the terminal. In such a case, the input 
state program merely demultiplexes the data into the 
line-oriented input buffers. Then the block is sent to the 
OPS level TIP which has a separate set of text processing 
programs for input data. The OPS level TIP calls the text 
processor in the same way that the text processor is 
called to convert downline data. If at all possible, this 
two-pass text processing should be avoided. The pro- 
cessing cost of translating characters, both upline and 
downline, normally uses at least 50% of the available NPU 
resources. 
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NOTES TO FIGURE 1-4: 

1. The TIP calls PTREGL directly to determine if input is allowed at this time. 

2. The TIP calls the command driver (PBCOIN) to initiate input processing. Parameters are passed in the 
command packet (NKINCOM). 

3. The Multiplex subsystem prepares the hardware for input processing. 

4. When the next input character arrives, it is framed and placed in the circular input buffer. The frame 
consists of an address. If a line status word is available, it is added to the data packet. 

5. The multiplex subsystem uses the number of the line to locate the input state program for that line and 
the buffer assigned to receive the data. Then the input processor converts the character as directed by 
the input state program. 

6. The multiplex subsystem reports an end of input condition to the OPS level TIP (optionally to the mux 
level TIP) by means of a worklist entry. 

7. The TIP performs whatever operations are needed to finish the input processing. Then it passes the block 
to the BIP. 

8. The BIP passes the block to the HIP or LIP, to be sent upline to the host. 

Figure 1-4. Simplified Upline Message Flow 
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MATERIALS NEEDED FOR WRITING A TIP 



This section lists the documents that are useful to have 
available when w/riting a TIP. The value of each of the 
items to a TIP virriter is also defined. 

CCP REFERENCE MANUAL 

This manual gives a general description of CCP's external 
characteristics. Appendices to the reference manual list 
all the code sets supported by the standard CCP TIPs: 

• ASCII 

• Teletype paired ASCII 

■ Bit paired ASCII 

• Binary coded decimal (BCD) 
« External BCD 

• External BCD - APL 

■ Correspondence 

• Correspondence - APL 

■ Display 

• EBCDIC 

The reference manual also contains a description of error 
messages and halt codes. 

LANGUAGE AND LANGUAGE 
SUPPORT MANUALS 

Compilation of CCP programs and building of the CCP 
load file is done in the host computer. Four source 
languages are used to write the CCP programs. A set of 
directives is used to compile and integrate a TIP into 
CCP. Three of these source languages are used by the TIP 
writer. These are as follows: 

• PASCAL language. This is used to write the 
OPS-level programs, and any Mux-2 level pro- 
grams. 

• State programming language. This is used to 
write the input state programs and the text pro- 
cessing state programs. 

■ Macroassembly language. The TIP writer can use 
this occasionally in the OPS-level programs. 

The fourth language (microassembler) is used only in CCP 
firmware level programs, such as the input processor or 
the text processor. The TIP writer never uses this 
language. 

Link edit and library maintenance directives provide the 
commands used to compile the TIP modules and to enter 
the TIP into the CCP build (load file). 



CYBER CROSS REFERENCE MANUALS 

The CYBER CROSS compilers and support programs allow 
the user to write programs for the NPU in languages 
defined in the last paragraph, and to use the large and 
efficient resources of a CYBER 70 or 170 to compile the 
programs, to debug them, and to build the load file which 
is used by the host to load the NPU. 



Five manuals are included in the CYBER CROSS set: 

• CYBER CROSS System PASCAL Compiler Ref- 
erence Manual. This manual defines the PASCAL 
language and describes how to obtain cross ref- 
erence listings. 

■ CYBER CROSS System Macroassembler Refer- 
ence ManuaL This manual defines the macro- 
assembler rules. The macroassembler is used as 
the basis of the specialized state programming 
language. 

• CYBER CROSS System Microassembler Reference 
Manual. This manual defines the microassembler 
rules. 

• CYBER CROSS System Link Editor and Library 
Maintenance Reference Manual. This manual ex- 
plains the use of the link editor which is used to 
initialize the CCP data structures. It also defines 
the format of the CCP library which holds the 
modules from which the NPU load file is con- 
structed. 



PASCAL LANGUAGE REFERENCE 

The analyst may wish to read some background infor- 
mation in the theory and use of PASCAL coding. This can 
be obtained in a highly usable text: 

t PASCAL User Manual and Report, Second Edition 
Kathleen Jensen and Niklaus Wirth 
Springer Verlag, 1974 

The text can be obtained through any technical book 
dealer. 



CYBER UPDATE REFERENCE MANUAL 

The UPDATE programs provide the user with an easy 
method of modifying the existing CCP libraries. 



STATE PROGRAMMING LANGUAGE REFERENCE MANUAL 



This manual contains the rules for writing programs in 
state programming language. The user must write all 
input state programs and text processing state programs 
in this language. The manual defines each state 
instruction. It also contains a description of the modem 
state programs. These are a set of common support 
modules for processing status information from the 
communication line adapters. 



NOS 1 INSTALLATION HANDBOOK 

This manual describes the method of installing the NOS 
installation tapes which include the CCP files. The 
manual also describes the standard build procedure for 
CCP. 
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HARDWARE REFERENCE MANUALS 



PASCAL X-REF LISTING 



Several hardware reference manuals may be of use in 
helping the TIP writer to understand the hardware con- 
straints of the NPU. These are as follows: 

■ 255X Host Communications Processor Reference 
Manual. This describes the hardware environment 
of the NPU. 

• 2560-1/-2/-3 Synchronous Communications Line 
Adapter Hardware Maintenance Reference Man- 
ual. This describes the hardware environment of 
the low and medium speed line controllers. 

• 2561-1 Asynchronous Communications Line Adapt- 
er Hardware Maintenance Reference Manual. This 
describes the hardware environment of the asyn- 
chronous line controllers. 

■ 2563-1 Synchronous Communications Line Adapter 
Hardware Maintenance Reference Manual. This 
describes the hardware environment of the bit 
insertion line controllers (HDLC, X.25). 



TERMINAL PROTOCOL RULES 

Each terminal manufacturer should supply an adequate 
description of the terminal's protocol. This must contain 
the code definition (including any variations particular to 
the terminal) of all symbols used by the terminal. It 
should also include the set of default characters used for 
non-recognized codes. 



LISTINGS 

It is often useful to have listings, both of the 
base/multiplex subsystem/BIP and of other TIPs, to deter- 
mine how other programmers have solved message han- 
dling or interface problems. 

CAUTION 

The TIP writer should note that TIPs in 
the standard CCP system use techniques 
that are in conflict with the guidelines set 
forth in this manual. CDC will support 
only those TIPs that are written to con- 
form to the rules set forth in this manual. 



MASTER AUDIT LISTING 

This is a complete source listing for CCP. It is obtained 
by using the method described in the UPDATE Reference 
Manual. 



PASCAL cross-reference listings are available for all 
PASCAL programs. The method for producing such 
listings is given in an appendix of the PASCAL Compiler 
Reference Manual. If the user has the maximum CCP 
system (HIP, LIP, and at least three standaj.^ TIPs) all the 
CCP modules cannot be run in a single cross-reference 
listing. The user should split his cross-reference job into 
two or more X-REF listings. 



PASCAL LISTING 

The standard build procedure preserves (as files) the 
listings containing PASCAL code. These files can be 
copied to the printer for use in reviewing the base system, 
the interfaces to the TIP, and TIP coding. 



ASSEMBLY LISTINGS 

Two assembly listings are also supplied by the standard 
build procedure: 

■ Base modules and modem state programs: These 
listings are useful as examples of input 
parameters and field initialization requirements 
for base programs called by the TIPs. The modem 
state program listings show how control passes to 
the TIP input state programs. 

• TIP state programs: This listings provide coded 
examples of methods used by TIP writers to solve 
the character by character protocol processing 
problems for their equipment. The listings also 
show how to pass control from the state level to 
the OPS level TIP. 

Assembly listings contain code conversion tables, and 
state instruction definitions in macroassembly format. 



MPLINK LISTING 

A set of MPLINK listings are provided for each CCP 
system variant. These listings indicate the program 
module addresses. 



MPEDIT LISTING 

The MPEDIT listing shows the global tables and variables 
which are initialized in the standard CCP system. This 
includes all the fields and variables initialized by the 
standard TIPs. 



OBJECT CODE LISTINGS 



The PASCAL compiler produces a set of listings of the 
NPU instructions which are the result of the compilation. 
This listing can be helpful in debugging code. 
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DESIGN CONSIDERATIONS 



The interna! structure of a TIP is determined by the 
characteristics of the terminal's protocol, by the inter- 
faces to the rest of CCP, and indirectly to the application 
programs which are used in the host. Usually a TIP 
supports more than one terminal. A TIP can support a 
variety of related terminal types. 



When the OPS monitor passes control of the NPU to the 
TIP, the monitor also passes the worklist parameters to 
the TIP. The TIP must have an entry structure that is 
able to determine the exact task to be performed. This is 
often done by switching to the appropriate TIP program 
based on the workcode in the worklist. 



Because of the difference in the rates at which line- 
related events and NPU-related events occur, the TIP 
must handle conditions where a terminal event is to occur 
after a period of time, rather than immediately. The TIP 
must therefore have programs dependent on waiting for a 
terminal event to occur. Since the TIP may be required to 
handle several similar terminals on individual lines, each 
at its own stage of processing a message, the TIP must 
have reentrant code. 

In planning the structure of a TIP, the writer must con- 
sider the following: 

• The methods which the system uses to access the 
TIP 

• The structure of the interfaces the TIP must use 
to access the system 

• The use of local and global variables 



ENTRY CONDITIONS 

CCP uses three types of entry into the TIP: 

• The normal processing entry is by means of a 
worklist to the OPS level TIP programs. The TIP 
is called to continue processing a message or an 
I/O status change. This call is made by the 
OPS-level monitor. 

• A high priority entry point can be provided for the 
TIP to process interrupt-driven tasks on the Mux-2 
level. This call is made by the multiplex sub- 
system's worklist handler. 

• A direct entry is made to handle initialization of 
those variables in the Terminal Control Block 
(TCB) which are unique to this TIP. This is a 
direct (return jump) call from the service module. 
(This is theoretically optional, but is in fact 
required on all but the simplest TIPs.) 



MUX-2 LEVEL ENTRY 

The multiplex subsystem enters the TIP's Mux-2 level 
entry (if it is defined) to process certain types of priority 
tasks. This entry appears to be a worklist-driven call, but 
it is in fact a direct call using a return jump. OPS-level 
processing may have been interrupted by a Mux-2 level 
call. Therefore any shared OPS-level and Mux-2 level 
procedures must be written using reentrant code. 



TCB INITIALIZATION 

The call to initialize those TCB fields that are unique to a 
terminal must take place before using the terminal for the 
first time. 



LOCAL AND GLOBAL VARIABLES 

CCP's global variables are defined for all modules in the 
system. Since these globals are reserved for system use, 
they may change as the system changes. Therefore the 
TIP writer should avoid accessing such fields, and should 
avoid defining system globals unless it is absolutely nec- 
essary. 

The necessary uses of system globals are as follows: 

■ Variables to be initialized by the build process 
must be globally defined. The TIP writer must 
provide MPEDIT declarations to specify the values 
to be preset. The MPEDIT program locates a 
variable to be initialized by its associated entry 
point name. The PASCAL compiler allows only 
global variables to have entry point names. 

■ In some cases, global variables are also needed to 
pass parameters between modules of a TIP. This 
is needed when the size of the TIP exceeds the 
capacity of the compiler to place all TIP code in a 
single module. 



OPS LEVEL ENTRY 

The OPS-level TIP is an event-driven module which must 
surrender control of the NPU for all wait conditions. Sys- 
tem modules external to the TIP (or the TIP itself) request 
the TIP to execute a task. The tasks are queued in a list 
of unexecuted tasks. The Worklist Control Block (WLCB) 
is the data structure which handles this task list. Each of 
the tasks are called a worklist entry (WLE). Unsolicited 
worklists are generated outside of the TIP. Solicited 
worklists are generated by the TIP itself. 



Local variables are used by the TIP writer as needed. 
Unfortunately, reentrancy requirements can conflict with 
such use. Local variables within a TIP should never be 
assumed to hold valid information after the TIP has given 
up control of the NPU to wait for an external event to 
occur. 

All variables should be defined uniquely. Multiple defi- 
nition of variables may compromise the maintainability of 
the system. 
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TIP REENTRANCY 

Once the OPS level TIP is given control of the NPU, it is 
allowed to execute until the TIP voluntarily returns con- 
trol to the system. (Of course, this priority level may be 
interrupted one or more time for higher priority tasks, but 
such operations are invisible to the OPS level TIP.) The 
TIP defines the points where reentrancy is permitted. 
This matter is discussed in detail in section 8. The system 
and the compiler do not provide sufficient capabilities to 
code a TIP without considering reentrancy. 



BLOCK PROTOCOL 

Data is transported within the network using the block 
protocol. The TIP has the responsibility of placing the 
data in block format before it passes it to any other 



module, and the system provides interface modules to 
move the blocks (and in some cases, to provide additional, 
specialized formatting). The TIP must use these inter- 
facing transport modules. The TIP is not allowed to 
develop its own transport mechanisms in avoidance of 
these system-provided interfaces. 



UNDOCUMENTED SYSTEM INTERFACES 

The system modules and the TIPs are compiled together in 
a single CCP compilation. As the TIP writer designs his 
TIP, he may become aware of many system modules and 
globial variables that are reserved for system use. The 
TIP writer should not use these modules and variables, 
since CDC reserves the right to alter or delete any of 
them at any time. CDC warrants only to maintain the 
interfaces that are defined in this manual. 
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IMPLEMENTATION CONSIDERATIONS 



Implementation of a new TIP requires the following: 



Coding the PASCAL OPS-level and Mux-2 level 
programs 

Coding the state programs (input and text pro- 
cessing) 

Coding the system global changes 

Coding the initialization directives for MPLINK 
and MPEDIT 

Coding the system build directives 



Each of these coded programs and directive sets are 
placed in various system and user supplied COMDECKS 
and are added to the system library on the CYBER host. 

CHANGES TO THE BASE SYSTEM 
GLOBALS 

Adding a TIP to the system requires that several data 
structures be altered to make room for tables that the TIP 



needs, and to provide standard mnemonics. Extensions are 
required to the worklist control block (WLCB), the TIP 
type table, and the terminal control block (TCB). 



WORKLIST CONTROL BLOCK (WLCB) 

A WLCB is defined for each TIP. It indicates the address 
of the TIP'S OPS-level entry point. The TIP writer must 
add the following indices to COMDECK CONSTR4: 

• BOUWLl 

■ B0UWL2 

■ B0UWL3 

■ B0UWL4 

The values selected must be in increasing numerical order 
and begin with the former value of BODUMMY. BO- 
DUMMY is always the last entry, its value is one greater 
than B0UWL4. The TIP writer must initialize the entries 
used in the control array, as described in section 12. The 
format of the worklist entry table is shown in table 4-1. 



TABLE 4-1. WORKLIST CONTROL BLOCK 



OPS-Level Programs : 

These worklists are serviced by the OPS monitor program. They are also part 
of the worklist array. New entries must be added at the end. The last entry 
must be BODUMMY which is equal to the last TIP worklist value. 



Type/Value 



= 8 
= 9 
= 10 
= 11 
= 12 
= 13 
= 14 



BOCHWL 

BOINWL 

BOMLWL 

BOSMWl, 

BOTIWL 

BOTYWD 

BOLIWL 

BODGWL = 15; 

BOCOWL = 16; 

BOHDLC 

B0M4WL = 18; 

BOTTYWL = 19; 

BOHASP = 20; 

B027WL = 21; 

BOHHWL = 22; 
yBODUMMY = 23; 
^BOASYNC = BOTTYWL; 



-Delete this card and add: 



BOVWLl = 23; 
B0VWL2 = 26; 
BODUMMY = 27; 



Meaning 



CONSOLE PROGRAM 

INTERNAL PROCESS 

MLIA INTERRUPT HANDLER 

SERVICE MODULE 

TIMING SERVICES 

TIP DEBUG 

LINE INITIALIZER 

ONLINE DIAGNOSTICS 

HOST INTERFACE PACKAGE (HIP) 

HDLC LIP 

MODE 4 TIP - BVT 

MODE 3 TIP - TTY - IVT 

HASP TIP 

2780/3780 TIP 

HASP/ 360 HIP 

DUMMY FOR CONSOLE 

ASYNC TIP 
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TIP TYPE TABLE 



USER GLOBAL CHANGES 



The TIP type table defines the characteristics of the TIP 
and provides linkage to the configuration control para- 
meters. The table is expanded for the four possible user 
TIPs, and standard mnemonics are defined. The TIP 
writer must expand the SYTIPTYPT array in COMDECK 
TYPE and add the following indices to the COMDECK 
CONSTR4: 

• NOUTTl = 12; USER TYPE 1 

• N0UTT2 = 13; USER TYPE 2 
■ N0UTT3 = 14; USER TYPE 3 

• N0UTT4 = 15; USER TYPE 4 

These values for the TIP type are permitted in the Net- 
work Definition Language (NDL). The content of the TIP 
type tables must be initialized by the TIP writer, as 
explained in section 12. Table 4-2 shows the required 
changes. 



The user must define the arrays which are used by the 
service module to process the line and terminal con- 
figuration options. Four arrays are added to the user- 
supplied VARtip COMDECK for line and terminal 
configuration. These tables define the field descriptor 
tables (line and terminal) and the action tables (line and 
terminal). 

NOTE 

In the following COMDECK descriptions, 
the COMDECKs have a name AAAtip 
where AAA is a system defined deck type 
and TIP is a three character mnemonic 
supplied by the TIP writer. 



TABLE 4-2. SIT, TIP TYPE AND SUBTYPE, AND TERMINAL CLASS 



System Interface Table Types : 



Type 



Value 



SYLCBP = ARRAY HLRANGE OF BZLCBF; 

SYLINO = ARRAY HLRANGE OF BOLINO; 

SYENTY = ARRAY BCPRILEVEL OF BWWORKLIST; 

SYLTYT = ARRAY INCLTYP,!. .HKRC30UT OF NBLTYE; 

SYPRTT = ARRAY 0..1 OF NAPCRY; 

SYCTCT = ARRAY NOLNSPDS OF NICTCY; 

SYTMTB = ARRAY COTDPGMS OF CBSYTMT; 

SYTECT = ARRAY NOTCLASS OF NJTECY; 

SYTIMTBL = ARRAY 0..1 OF BZLTIME; 

SYTIPTYPT = ARRAY NOHDLC. .NOCLCIAfi OF TIPTYPE; 

SYOVLCB 



ARRAY NOHDLC 
RECORD 

DCOVID 

DCOVLST 

DCLBN 

DCBN 



Change this name to: 
N0UTT4 



INTEGER; 
DOOVLSTATE; 
INTEGER; 
JSASCIISET; 



System Interface Table : 



Type 



Value 



SITTBL 



PACKED RECORD 
SIENTY 
SITMTB 
SIWLCB 
SIDBSIZE 
SITPSIZE 
SINJTEC 
SITIMTBL 
SITIPTYP 
SIOVLBLK 
SILCBP 



SYENTY; 

SYTMTB; 

BYWLTY; 

BECTPTR; 

BECTPTR; 

SYTECT; 

SYTIMTBL; 

SYTIPTYPT; 

SYOVLCE; 

SYLCBP; 



c 



Add: 

NOVTCl = 28; 
N0VTC4 =31; 



Meaning 



OVERLAY CONTROL BLOCK 
OVERLAY ID 
OVERLAY STATE 
LAST BLOCK NUMBER 
BLOCK NUMBERS LOADED 



Meaning 



POINTER TO 
POINTER TO 
POINTER TO 
POINTER TO 
POINTER TO 
POINTER TO 
POINTER TO 
POINTER TO 
POINTER TO 
POINTER TO 



BWWLENTRY 

CBTIMTBL 

BYWLCB 

BEDBSIZE 

BETPSIZE 

NJTECT 

BLTIMTBL 

BJTIPTYPT 

SYOVLCB 

HALCBP 
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Field Descriptor Tables 

The host software must be modified to add new para- 
meters for the configure or reconfigure terminal service 
messages. Messages are sent downline from the host to 
initialize fields in these tables. These configuration mes- 
sages state the values to be placed in the fields by means 
of a field number/field value (fn/fv) pair. The tables are 
required, even though the entries may be empty. The 
following arrays are added to the VARtip COMDECK: 

• VALnFDT: ARRAY 0..x OF DDFDTENTRY: 
LINE FIELD DESCRIPTOR 

• VATnFDT: ARRAY 0..x OF DDFDTENTRY: 
TMNL FIELD DESCRIPTOR 

where: 

n has the range of 1 through 4, corresponding to user 
TIP 1 through 4. 

X is the number of fn/fv pair entries. 

The TIP writer must initialize these tables as described in 
section 14. 



Action Table 

The host uses line and terminal configuration service 
messages to send to downline user-defined line or terminal 
options. The variables are sent in the form of a field 
name/field value pair (fn/fv). Action tables define the 
appropriate type of initialization that is to be performed 
while setting up each of these fn/fv pairs. The user 
defines the following arrays in the VARtip COMDECK: 

• VALnAT :ARRAY l..x OF DFATENTRY 
LINE TABLE ACTIONS 

• VATnAT :ARRAY l..x OF DFATENTRY 
TERMINAL TABLE ACTIONS 

where: 

n has the range of 1 through 4 corresponding to user 
TIP 1 through 4. 

x is the number of entries. 

The TIP writer also must initialize these action tables as 
described in section 12. 



STATE PROGRAMS 

State programs include the input state programs, the text 
processing state programs, the code translation tables, 
and common definitions. The state programs use state 
processing instructions almost exclusively, although any 
valid macroassembler instruction can be used. The fre- 
quently used macroassembler instructions are as follows: 

• EQU to equate a protocol name with a value, or to 
define usage for a file 1 register 

• EXT to define entry points, such as a translation 
table address 

• ENT to define the entry point to a state program 

■ MAC to define the pointers table for a state pro- 
gram 



• EMC to end the state program pointers table 
macro definition 

I SPC to add blank lines to a listed output 

• EJT to insert a top-of-page command in a listed 
output 

• ADC for address constants 

The state programming language is described in detail in 
the State Programming Language Reference Manual. The 
deck structure for compiling state programs using UP- 
DATE is described in the UPDATE Reference Manual. 
There are two common definition decks: 

■ MUXMACROS defines the input state instructions 
(macros) for the macroassembler. It also contains 
EQU statements for multiplex subsystem con- 
stants and for workcodes (AOWKn). 

■ REL4CONST contains EQU statements for the IVT 
and BVT constants that are common to all CCP 
programs. 

Translation tables are written using macroassembler 
statements exclusively. The macroassembler language is 
described in detail in the CYBER CROSS System Macro- 
assembler Reference Manual. 

BASE SYSTEM DATA STRUCTURE 
OVERLAYS 

The TIP writer probably will need to define the names of 
fields in the user portions of the following tables: 

• Line control block (LCB) 

• Terminal control block (TCB) 

• Text processing control block (TPCB, a subset of 
the multiplex line control block NCLC8) 

• CE error file entry (CNCE) 



LCB OVERLAY 

The entries are made in the tipLCB user COMDECK, and 
are PASCAL statements of the form: 



1:( 



BZname : type; description 



); 



The prefix BZ is used for all LCB fields, and the name 
must be unique. 



TCB OVERLAY 

The entries are made in the tipTCB user COMDECK, and 
are PASCAL statements of the form: 

1:( 

BSname : Array; IVT fields 
0..6 
OF INTEGER 
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The prefix BS is used for all LCB fields, and the name 
must be unique. 



variables, for expanding the new TIP's system giobals, for 
defining the service module tables, and for defining new 
CE error file messages. 



TEXT PROCESSING CONTROL BLOCK OVERLAY 

The entries are made in the tipMLCB user COMDECK, 
and are PASCAL statements of the form: 

l:(CNname : type; field description 



); 

The prefix NC is used for all TPCB fields, and the name 
must be unique. 



CE ERROR FILE ENTRIES 

The entries are made in the tipCEFILE user COMDECK, 
and are PASCAL statements of the form: 

l:(CNname : type; field description 



); 

The prefix CN is used for all CE file fields, and the name 
must be unique. 

TERMINAL CHARACTERISTICS TABLE 

The TIP writer must create new tables to define the 
terminal classes to be used with his TIP. These tables 
define default values for IVT parameters to be used during 
terminal configuration. The TIP writer adds the indices 
for the four user terminal classes by adding constants to 
the CONSTR4 COMDECK. Entries are of the form: 

• NOUTCl = 28; USER TERMINAL CLASS 1 

• N0UTC2 = 29; USER TERMINAL CLASS 2 

■ N0UTC3 = 30; USER TERMINAL CLASS 3 

■ N0UTC4 = 31; USER TERMINAL CLASS 4 

These values are permitted to be defined in the Network 
Definition Language. 

The terminal class arrays must also be extended to include 
the tables. This is done by adding the following state- 
ments to the TYPE COMDECK: 

NOTCLASS = 0..31; TERMINAL CLASS 

NOTTYP = NOTMLIA..N0UTC4; TERMINAL CLASS 

The content of the new entries in the arrays are supplied 
by the TIP writer using the guidelines of section 12. 

ADDING A TIP TO THE PROGRAM 
LIBRARY 

The TIP writer must add to the program library all the 
COMDECKs containing code for global modifications, 
PASCAL TIP code, microassembly language TIP code (this 
includes the state language programs), and the global 
initialization statements. 



GLOBAL MODIFICATIONS 

Modifications are made for adding TIP-defined global 



TIP-Defined Global Variables 

User giobals are placed in their own UPDATE COM- 
DECKs. The names are defined to be easily recognized. 
Calls to these COMDECKs are placed in the following 
standard system COMDECKs: 



COMDECK Name 



CONSTUSR 



TYPEUSER 



VARU5ER 



VALUSER 



FWDUSER 



Content of COMDECK 

Call to the TIP's constants defi- 
nition COMDECK 

Call to the TIP's types definition 
COMDECK 

Call to the TIP'S variables defi- 
nition COMDECK 

Call to the TIP's values definition 
COMDECK 

Call to the TIP's forward defi- 
nition COMDECK 



Examples of each of these COMDECKs are given in 
figures 4-1 through 4-5. 



*COMDECK CONSTUSR 






*$J+ PAGE EJECT 






******************************** 1 


* 




* 


* USER CONSTANTS CALL 


DECK 


* 


* 




* 


******************************** 1 


*CALL C0NSTR4 






*CALL CONBLK 






*CALL IPCON 






*IF DEF,SVM0DULE,1 






*CALL SVMCONST 






*IF DEF,0LDIAG,4 






*IF DEF,CIAIA,1 






*CALL CONODC 






*IF -DEF,CLAIA,1 






*CALL CONOLD 






*IF DEF,HIP,1 






*CALL CONHIP 






*IF DEF,M0DE4,1 






*CALL C0NMD4 






*IF DEF,TESTGEN,1 






*CALL CONTST 






*IF DEF,LDDMP0,1 






*CALL CONLDP 






*IF DBF, IVT, 1 






*CALL CONIVTC 






*IF DEF,ASYNC,1 






*CALL CONASYNC 






*IF DEF,HLIP,1 






*CALL CONLRZQSS 






«ENDIF 






If a new TIP is written 


with 


global constants 


defined, the user must 


Supply a call: 1 


*CALL tipCON 






A tipCON COMDECK defines the 


tip's constants. 



Figure 4-1. TIP Constants 
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*COMDECK TYPEUSER 
*$J+ PAGE EJECT 

* * 

* USER TYPE DECLARATIONS DECK * 

* * 

*IF DEF , SVMODULE , 1 
*CALI, SVMTYPE3 
*IF DEF,ASYNC,1 
*CALL TYPASYNC 
*IF DEF,0LDIAG,4 
*IF DEF,CLAIA,1 
*CALL TYPODC 
*IF -DEF,CLAIA,l 
*CAIX TYPOLD 
*IF DEF,LDDMP0,1 
*CALL TYPLDP 
*IF DEF,LRZQSS,1 
*CALL TYPLRZQSS 
*IF DEF.IVT.l 
*CALL TYPIVTC 
*IF DEF,HASPT1P,1 
*CALL HASPTYPE 

If a new TIP is written with global types defined, 
the user must supply a call: 

*CALL tipTYPE 

A tipTYPE COMDECK defines the TXP's TYPE statements 



*COMDECK VALUSER 




1 


****-k**ick******icirk**i!-k*-k-kirk*** \ 


* 




* 


* USERVALUES DECLARATION 


* 


* 




* 


*IF -DEF.OVLYBUILD 






*CALL IPVAL 






*IF DEF , SVMODULE , 1 






*CALL SVMVALUE 






*IF DEF,ASYNC,1 






*CALL VALASYNC 






*IF DEF,HASPTIP,1 






*CALL HASPVAL 












*IF DEF.OVLYBUILD 




with new global values 


VALUE 




defined, the user must 


■k******************** 


supply a call: 


** 


** 




** VALUES 


** 


*CALL tipVAL 


** 


** 




■lrk*****-k****irk******* 


A tipVAL COMDECK defines 


*ENDIF 




values for the TIP 


*IF DEF,0LDIAG,4 




defined variables 


*IF DEF,CLAIA,1 






*CALL VALODC 






*IF -DEF,CLAIA,1 






*CALL VALOLD 







Figure 4-4. TIP Value Declarations 



Figure 4-2. TIP Types 



*COMDECK VARUSER 
********************************** 

* * 

* USER VARIABLES DEFINITIONS * 

* * 
********************************** 
*IF -DEFjOVLYBUILD 

*CALL IPVAR 
*CALL VARBLK 
*IF DEF, SVMODULE,! 
*CALL SVMVAR 
*IF DEF, HIP, 1 
*CALL VARHIP 
*IF DEF,M0DE4,1 
*CALL VARMD4 
*IF DEF,TESTGEN,1 
*CALL VARTST 
*IF DEF,HASPTIP,1 
*CALL HASPVAR 
*IF DEF,ASYNC,1 
*CALL VARASYNC 
*IF DEF,HLIP,1 
*CALL VARHLIP 
*ENDIF 

*IF DEF,0LDIAG,4 
*IF DEF,CLAIA,1 
*CALL VARODC 
*IF -DEF,CLAIA,1 
*CALL VAROLD 
*IF DEF,LDDMP0,1 
*CALL VARLDP 

If a new TIP is written with new global arrays 
defined, the user must supply a call: 

*CALL tipVAR 



*C0MDECK FORWDUSER 
********************************* 

* * 

* USER FORWARDS DECLARATION * 

* * 
********************************* 
*IF DEF,M0DE4,1 

PROCEDURE PT4CSTATE(V3IN: BOOLEAN ; V30N=BOOLEAN ) ; 
FORWARD; 

*CAU SVMFWD 
*IF DEF,ASYNC,1 
*CA1X ASYNCFWD 
*IF DEF,IVT,1 
*CALL IVTFWD 



Forward declarations may be needed 
for a new TIP. In this case, the 
user must supply a call ; 

*CALL tipFWD 

These declarations solve the 
forward calling requirements of the 
PASCAL compilation. 



Figure 4-5. TIP Forward Declarations 



Figure 4-3. TIP Variable Arrays 
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The TIP writer should define a three character mnemonic 
to identify the TIP. In all the examples which follow, the 
mnemonic "tip" is used. The following list specifies the 
COMDECK for TIP-defined globals: 



COMDECK Name 

tipCON 

tipTYPE 

tipVAR 

tipVAL 

tipFWD 



Contents 

TIP-defined constants 
TIP-defined types 
TIP-defined variables 
TIP-defined value initializations 
TIP-defined forward declarations 



The TIP-defined variables may be initialized during the 
system build procedures by means of MPEDIT directives. 
The directives are contained in unique COMDECKs as 
shown: 



COMDECK Name 

ZCNtip 
ZARtip 
ZEXtip 



Contents 

TIP-defined constants 

Array sizes for TIP-defined arrays 

Variable initialization statements 



These uniquely defined COMDECKs are called from the 
standard system COMDECKs; 



COMDECK Name 

ZCONUSER 
ZARRUSER 
ZEXUSER 



Contents 

Call to user edit constants 

Call to user array size definitions 

Call to user edit directives 



An example of this COMDECK structure is shown in 
figure ^-6. 



*COMDECK ZCONUSER 


User adds a ca!l to his 


* 


constant defining deck, 


* 


ZCNtip. User defines 


* 


ZCNtip as a COMDECK. 


*IF DEF, tipnam,! 




*CALL ZCNtip 
* 
* 




*COMDECK ZARRUSER 


User adds a cal! to his 


* 


array defining deck, 


* 


ZARtip. User defines 


* 


ZARtip as a COMDECK. 


*IF DEF, tipnam,! 




*CAII, ZARtip 

■k 
■k 
•k 




*COMDECK ZEXUSER 


User adds a call to his 


* 


field initialization 


* 


definition deck, ZEXtip. 


* 


User defines ZEXtip as a 


*IF DEF, tipnam,! 


COMDECK. 


*CALL ZEXtip 




* 




* 




* 





GLOBAL EXPANSION FOR A NEW TIP 

Standard system globals must be expanded to provide the 
necessary control linkage to base system routines. The 
following standard COMDECKs are referenced: 



COMDECK Name 



CONSTR4 



TYPE 



Necessary Additions 

• Worklist entry indices for the 
new TIP 

• New user terminal type names 

■ New user TIP type names 

■ Expanded array for new TIP 
types 

• Expanded array for new ter- 
minal classes 



MPEDIT statements in the ZEXtip COMDECK are used to 
initialize the values in the expanded arrays created by 
these tables. These MPEDIT statements initialize the 
worklist control block, the terminal type table, and the 
terminal characteristic table (terminal class). Guidelines 
for using these statements are given in section 12. 

Data structures are also customized for each new TIP by 

adding overlays to existing structures. In each case a 

unique name should be assigned for a COMDECK con- 
taining the type declarations: 



COMDECK Name 

tipLCB 
tipTCB 
tipMLCB 



Contents 

TIP-defined extention to LCB 
TIP-defined extention to TCB 
TIP-defined extention to TPCB 



The TIP writer should insert a call to these TIP defined 
overlays in the corresponding system COMDECKs: 



COMDECK Name 



Contents 



TYPELCB 
TYPETCB 
TYPENCLCB 
Examples of these COMDECKs are given in figures 4-7. 



Contains calls to TIP-defined over- 
lay 

Contains calls to TIP-defined over- 
lay 
Type declarations for the TPCB 



SERVICE MODULE TABLES 

The service module requires four tables to be defined for 
each TIP in the system. These tables define the TIP 
specifications for processing line and terminal table 
construction. In general, these tables define the valid 
ranges of values provided by a user when the system is 
configured. The table definition may be placed either in 
the TIP'S variable definition COMDECK, or in a unique 
COMDECK. 



COMDECK Name 

unique name 
unique name 
unique name 
unique name 



Contents 

LCB field descriptor table 
TCB field descriptor table 
LCB action table 
TCB action table 



Figure 4-6. Global Initialization 



If the user determines that the TIP requires one or more 
new CE error message types, an overlay should be added 
to that data structure. 
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*COMDECK TYPELCB 
****************************** 

* * 

* LCB DEFN FOR RELEASE 4 * 

* * 
****************************** 
*IF DEF,M0DE4,1 

*CALL TMD4D2 
*IF DEF,HASPTIP,1 
*CALL HASPLCB 
*IF DEF,ASYNC,1 

*CALL ASYNCLCB __ -The user must put his call 

for the new TIP here: 

*CALL tipLCB 

The tipLCB deck is defined 
as a numbered overlay. 



*COMDECK TYPETCB 
****************************** 

* * 

* TCB DEFN FOR RELEASE 4 * 

* * 
****************************** 
*CALL TYPEIVT 

*IF DEF,M0DE4,1 
*CALL TMD4D1 
*IF DEF,HIP,1 
*CALL THIPDl 
*IF DEF,ASYNC,1 
*CALL TASYNC 
*IF DEF,HASPTIP,1 
*CALL HASPTCB 
*IF DEF,HLIP,11 
*CALL TYPIHLIP 



The user inserts his call 
for the new TIP here; 

*CALL tipTCB 

The tipTCB deck is defined 
as one or more overlays. 



*COMDECK TYPENCLCB 
********************************* 

* * 

* USER APPS FOR NCLCB ~ R4 * 

* * 
********************************* 

IF DEF,HASPTIP,1 

CALL HASPMLCB 

IF DEF,M0DE4,1 

CALL TMD403 
*IF DEF,ASYNC,1 

*CALL ASYNCMLCB —-The user inserts his call 

for the new TIP here: 

*CALL tipMLCB 

The tipMLCB deck is defined 
as one or more numbered 
overlays. 



The fallowing COMDECKS must be added: 

COMDECK Name Contents 

tipCEFILE TIP-defined overlay for CE error 

messages 

A call to this COMDECK is added to the standard system 
COMDECK: 



COMDECK Name 



Contents 



TYPECNCE Defines the CE error message over- 

lay. 

Figure 4-8 shows the CE error message COMDECK. 



*COMDECK TYPECNCE 






******************************** 




* RELEASE 4 CNCEFILE 


DEFNS * 




*******************************jt 




****************************************************] 






M0DE4TIP 


3:(VM4LINO 


: INTEGER 


LINE NUMBER 


VM4CA, 




CLUSTER ADDRESS 


VM4TA 


: B08BITS; 


TERMINAL ADMtESS 


VM4DT 


: NODEVTYP; 


DEVICE TYPE 


VM4TC 


: NOTCLASS; 


TERMINAL CLASS 


VM4SPARE 


: B02BITS; 


SPARE 


VM4ERRCNT 


: B06BITS); 


ERRCE COUNT 
HASP TIP 


4:(HSLIN0 


: INTEGER); 


LINE NUMBER 
HDLC LIP 


5:(HLIN0 


: INTEGER; 


LINE NUMBER 


HLNID 


: B08BITS); 


REMOTE NODE ID 
ASYNCTIP 


6:(ASYLIN0 


: INTEGER; 


LINE NUMBER 


ASYCA, 




CLUSTER ADDRESS 


ASYTA 


: B08BITS; 


TERMINAL ADDRESS 


ASYDT 


: NODEVTYP; 


DEVICE TYPE 


ASYTC 


: NOTCLASS); 


TERMINAL CLASS 


*CALL tipCEFILE 





Figure 4-8. CNCEFILE COMDECK 



PASCAL MODIFICATIONS 

The PASCAL portions of the TIP are added as a single 
COMDECK with the following name: 



COMDECK Name 



tipTlP 



Contents 



All PASCAL code for the user TIP 



This COMDECK is called from the standard system 
COMDECK as indicated: 



Figure 4-7. COMDECKS for LCB, TCB, and TPCB 



COMDECK Name 



Contents 



NOTE 

If these new types of error messages are 
used, changes to the host's engineering 
file analyzer will also be required. These 
changes are not discussed in this docu- 
ment. 



USERAPPS Call to PASCAL code for TIPs 

Figure 4-9 shows the PASCAL code COMDECK. 
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*COMDECK USERAPPS 

*$J+ 

*************************************** 

* * 

* USER APPLICATIONS PROGRAM CALLS * 

* * 
*************************************** 
*€ALL IP 

*IF DEF,HLIP,1 
*CALL HLIP 
*IF DEF.IVT 
*CALL FBFMAD 
*CALL PARSER 
*CAIX PTIVTCMD 
*ENDIF 

*IF DEF,HIP,1 
*CAtL HIP 30 
*IF DBTjMODEA,! 
*CALL M0DE4TIP 
*IF DEF,HASPTIP,1 
*CALL HASPTIP 
*IF DEF,ASYNC,2 
*CALL ASYIOOMS 
*CALL ASYNCTIP 
*IF DEF,0LDIAG,1 
*CALL OLDGOVL 
*IF DEF,LDDMP0,1 
*CALL LDMPOVL 
*IF DEF,SVM0DULE,1 
*CALL SVM 
*IF DEFjLRZQSS 
*CALL LRZQSS 
*ENDIF 




If a new TIP is written, 
the call must be 
included here: 

*CALL tipTIP 

This calls all OPS-level 
TIP COMDECKS. 



COMDECKs are defined for each module, the COMDECK 
name shduld be the same as the deck name (ident). 



*DECK ASMUSER 

NAM ASMUSER 

************************************* 



* DEVELOPMENTAL FILE ASSEMBLIES * 

* * 
************************************* 

DUMFIL NUM DUMMY CARD FOR MPLINK 

END ASMUSER 
*IF DEF, LRZQSS,! 
*CALL ASMLRZQSS 
*IF DEF,M0DE4,1 
*CALL REL4MD4 
*IF DEF,ASYNC,1 
*CALL REL4ASY 
*IF DEF, HASPTIP, 1 
*CALL HASPASSEM 
*IF DEF, HLIP, 1 
*CALL LI PI ST 
*1F DEF,0LDIAG,1 
*CALL ISPOLD 

-^ New TIP must add 

conditional definition 

here: 

*CALL namTIP 



Figure 4-10. ASMUSER Deck 



Figure 4-9. PASCAL Language COMDECK 



MACROASSEIVIBLY LANGUAGE MODIFICATIONS 

The macroassembler portions of the TIP (state pro- 
gramming language modules) are added as a single COM- 
DECK with the following name: 



COMDECK Name 



tipASSEM 



Contents 

All assembly language decks in 
the TIP 



This COMDECK is called from the standard system 
COMDECK as indicated: 



COMDECK Name 



ASMUSER 



Contents 

Call to TIP'S assembly language 
modules 



Figure 4-10 shows the PASCAL code COMDECK. 

Four separate assembly decks (i dents) should be defined 
for the TIP. These are the input states programs, the 
input translation tables, the output text processing state 
programs, and the output translation tables. If a second 
pass is defined for input processing, a fifth deck is also 
needed: the input text processing state programs with 
their associated input text processing translation tables. 
Any of these decks can be omitted if not needed. More 
decks can be defined to separate subfunctions, but in this 
case more build directives are required. If any macro- 
assembler programs are to be called from the PASCAL 
code, these can be specified as one or more i dents. 

To simplify the build directives, each program should have 
one entry point with the same name as the deck (ident). If 



BUILD PROCEDURE 

The completed source program is placed on the user input 
file UCCP, and the standard build procedures are 
followed. These procedures are described in the NOS 1 
Installation Handbook. 

The user TIP may be defined as a build option. However, 
if all systems are to contain the user TIP, the options may 
be omitted. The examples assume user TIPl is not a build 
option (UTIPl) and user T1P2 is a build option (UTIP2). 

Build options are involved in two different build steps: 
the step which generates the CCP object code library 
(CCPBLB), and the step which generates a CCP variant 
load module (CCPVAR). The CCP standard build 
procedures allow a TIP to be included in object library and 
excluded from a variant build by using the following 
procedures: 

Build step CCPBLB gets its TIP definition from a common 
deck called TIPDEFS. Build step CCPVAR gets it TIP 
definition through the TS parameter in the specified 
variant definition which is an entry in the USERBPS file 
(see the Expand section of the CYBER Cross Build 
Utilities Reference Manual). The TS parameter provides 
options for up to four user-written TIPs. When these 
options are selected, the fallowing define statements are 
generated: 

•DEFINE UTIPl 
»DEFINE UTIP2 
♦DEFINE UTIP3 
♦DEFINE UTIP4 

Figure 4-11 shows COMDECK TIPDEFS. User TIP 
definition should be inserted as indicated if the source 
code is conditional for compilation. 
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♦COMDECK TIPDEFS 

*TEXT DEFAULT TIP DEFINITIONS FOR FULL COMPILE/ASSEMBLY 

♦DEFINE M0DE4 

♦DEFINE ASYNC 

♦DEFINE ASYNCEXT 

♦DEFINE HASPTIP 

♦DEFINE X25 

♦DEFINE UTIPl -« — Define one to four 

♦DEFINE UTIP2 user TIPs 

♦ENDTEXT 



Figure 4-11. Compile Definition 



The rest of this section is concerned only with the 
CCPVAR build step, and assumes the user always wants to 
have the TIPs compiled. 

The TIP writer must add the following information to the 
Autolink input directives decks (see the Autolink section 
of the CYBER Cross Build Utilities Reference Manual): 

■ Application (APPL) directives for the new TIPs (a 
TIP is considered an application) (see figure 4-12) 



*COMDECK ALDEFS 




• 

DEFEASE 
DEFEASE 
DEFEASE 
DEFEASE 
DEFEASE 


= SVMODULE 
= IVT 




= COTISOLE 
= EASESYS 


(TIP is to be included in 
all builds) 


*IF DEF 
DEF = 
♦IF DEF 
DEF = 
*IF DEF 
DEF = 
*IF DEF 
DEF = 


, M0DE4 
M0DE4 
, HASPTIP 
HASPTIP 




UTIP2 
, HLIP 
HLIP 





Base definition directive if the user TIP is not a 
build option (see figure 4-13) 



Figure 4-13. Autolink Definition Directives 



Optional definition directive if the user TIP is a 
build option (see figure 4-13) 

COMDECK to describe the linking characteristics 
of the individual modules within the TIP (see 
figure 4-14) 

Calls to COMDECK (see figure 4-15) 



♦DECK ALIN DIR 



APPL = ASYNC 
APPL = M0DE4 
APPL = HASPIP 
APPL = UTIPl 
APPL = UTIP2 
APPL = HIP 



]- 



■New TIP directives 
defining the applications 



Figure 4-12. Autolink Application Directives 



♦COMDECK ALUTIPl 






MOD = UTIOPS (P = F, APPL 


= UTIPl) -1 


Used to 


MOD = UTIMI (P = P, APPL 


= UTIPl) 


generate 


MOD = UT1M2 (P = P, APPL 


= UTIPl) 


the linking 


, 




directives 


. 




for the 


, 




user TIP 


MOD = DTIMN (P = P, APPL = 


= UTIPl) 


modules 


♦COMDECK ALUTIP2 






MOD = UT20PS (P = F, APPL 


= UTIP2) 




MOD = UT2M1 (P = P, APPL 


= UTIP2) 




MOD = UT2M2 (P = P , APPL 


= UTIP2) 




MOD = UT2MN (P = P, APPL 


= UTIP2) - 





Figure 4-14. Autolink Module Directives 



♦DECK ALINPDIR 

• 

♦CALL ALASYNC 
♦CALL A1M0DE4 
*CAT,T. ALHIP 


♦CALL ALUTIP2 _ 
♦CALL ALHASP 


COMDECKS 



Figure 4-15. Autolink Application COMDECK Calls 
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PRINCIPAL DATA STRUCTURES 



The principal data structures used by the TIP are as fol- 
lows: 



Worklists, worklist control blocks, and worklist 
entries 

Line control blocks 

Terminal control blocks 

Command driver packets 

Mux LCBs (MLCBs) and text processing control 
blocks (TPCBs) 

Port tables 

TIP type tables 

Terminal characteristics tables 

Code translation tables 

Dynamic buffers 



This 
thai 



section discusses those aspects of the data structures 
are used by the TIP. 



WORKLISTS 

The worklist control block (WLCB) is the system data 
structure that controls entry to the user TIP. The TIP 
writer must initialize some worklist control block fields at 
build time. The run time TIP, however, cannot access the 
table directly. The TIP can extract fields from the global 
worklist variable, BWWLENTRY. Figure 5-1 shows the 
worklist control block and the worklist entries (WLE). The 
TIP must be able to decode entries from the Mux-2 level, 
from the base timer, from the service module, and from 
the BIP. The TIP can generate worklists to the service 
module. It is often useful to have the TIP generate work- 
lists to itself following the occurance of an event. The 
TIP writer must define a worklist for his TIP, and be able 
to interpret all uses of this worklist by other modules 
which request the TIP to perform a task. 



LINE CONTROL BLOCK ILCB) 

One line control block is assigned for each communication 
line adapter (CLA) which is attached to the NPU. The 
LCBs are contained in an array of fixed length tables 
which are built during system initialization. The TIP can 
access a few of the fields in the system-defined standard 
portion of the LCB. The TIP can access all the fields in 
the TIP-defined variable portion of the LCB. In some 
systems the variable portion may be longer than two 
words. 



To access LCB fields, the TIP uses a variable of type 
BZLCBP, as shown in the example below: 

VAR 

(Icbptr) : BZLCBP; 
BEGIN 

WITH(lcbptr) + DO 

BEGIN 



The LCB is defined in figure 5-2. The figure defines (1) 
all the fields and (2) the subset of fields that is available 
to the TIP. 

TERMINAL CONTROL BLOCK 

One terminal control block (TCB) is created for each ter- 
minal device that can support an independent data stream 
to a host application program. The TCB has two parts: 

• A base part. Only two boolean variables may be 
set by the TIP in this portion. 

■ A variable part used by the TIP. If the device is 
interactive, the variable part must include all the 
interactive virtual terminal (IVT) definitions. The 
TIP can read the IVT fields, but it cannot change 
them. The unused space in the variable portion is 
available for user TIP-defined fields. 

When the TIP accesses the TCB, it must use a variable 
pointer of the BOBUFPTR type. This is necessary since 
TCBs are contained in buffers. The TCB overlay type is 
BSTCB. A TCB is accessed as shown in the example below: 

VAR 

(tcbptr) : BOBUFPTR; 
BEGIN 

WITH (tcbptr) + . BSTCB DO 

BEGIN 



The TCB is defined in figure 5-3. The figure defines (1) 
all the fields (including the IVT parameters) and (2) the 
subset of fields that is available to the TIP. 



COMMAND PACKET 

The command packet is an area holding all the parameters 
that the multiplex subsystem requires when a request for 
I/O is made. The request takes the form of a call to 
PBCOIN, with the command packet attached. The TIP 
fills the command packet fields; it is the responsibility of 
the multiplex subsystem to alter the MLCB using these 
field values. 
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WORKLIST CONTROL BLOCK (ARRAY OF WLCB) 




WLCB 



15 


14 




i 8 


7 







Fl 




BYCNT 




BYPUT 




BYGET 


BYFEINC 


BYINC 


BYWLINDEX 


* 


* 


F2 


BYMAXCNT 


BYPAGE 




BYPRADDR 



Fl = BYCOUKTEND 

F2 = BYWLREQ 

* = reserved for CDC 



Field Name Definition 

BYCONTEND multiprocessor continue flag 

BYCHT number of WLEs 

BYPUT first WLE in chain 

BYGET last WLE in chain 

BYFEINC first entry index 

BYINC WLE size in words 

BYWLINDEX worklist index to WLCB 

BYWLREQ WLE sent to program if set true 

BYMAXCNT number of WLEs to process before next pass 

BYPAGE program page 

BYPADDR program address 



Figure 5-1. Worklist Control Block and Worklist Entries (1 of 2) 



5-2 



60474600 A 



Data structure for WLE from MUX Subsystem or Base Timer 



Word 


15 


14 




8 7 6 


5 












MMWTCOUNT 


1 


1 MMWKCOD 


1 


1 


MMLINO 


2 


MMIBP 


3 


* 


4 


* 


Field Name 

MMWTCOUNT 
MMWCCOD 
MMLINO 
MMIBP 




Type 

subrange 
subrange 
BOLINO 
BOBUFPTR 


Description 

wait count for timer WC 

work code 

line number 

buffer or TCB address 





Data structure for WLE to or from SVM or BIP: 



Field Name 

CMDATA 

CMWKCODE 

CMLINO 

CMPOINT 

CMPTR 



Type Description 

subrange variable use data byte 

subrange work code 

BOLINO line number 

BOBUFPTR pointer to buffer or TCB 

BOBUFPTR pointer to buffer or TCB 



15 




8 


7 







CMDATA 


CMWKCODE 1 






CMLINO 






CMPTR 



15 




8 


7 







CMDATA 


CMWKCODE 1 






CMPOINT 







Figure 5-1. Worklist»Controi Block and Worklist Entries (2 of 2) 



60474600 A 



5-3 



15 14 13 12 11 10 9 8 






BZLINO 


1 


BZTMRCHH 


2 


BZWTCOUNT 


BZOWNER 1 


3 


BZRETIADDR 


4 


BZRET2ADDR 


5 


Fl F2 


F3 


F4 


BZLTYP 


BZHO 


6 


BZCNFST 


BZUJSPD 


BZTCBCNT 


7 


F5 


F6 


F7 


BZ STATE 


F8 


F9 


BZWKCODE 


8 


BZTIPTYPE 




BZSUBTIP 


BZSVTIPYPE 


9 


BZSTIC.BZBTRANS 


A 


BZSTIC.BZBRCV 


B 


BZSTIC.BZCTRANS 


C 


BZSTIC.BZCRCV 


D 


BZTCBPTR 


E 


BZLBTQMUX 


F 
10 






VARIABLE PART 


ID 






Name 






De£ 


cription 





BZLINO 




BZTMRCHN 




BZWTCOUNT 




BZOWNER 




BZRETIADDR 




BZRET2ADDR 


Fl 


BZTAPEX 


F2 


BZCHECKQS 


F3 


BZSMRESF 


F4 


BZSMTO 




BZLTYP 




BZHO 




BZCNFST 




BZLNSPD 




BZTCBCNT 


F5 


BZTOUTPUT 


F6 


BZTINPUT 


F7 


BZDIS 




BZ STATE 


F8 


BZAUTO 


F9 


BZDIAG 




BZWKCODE 




BZTIPTYPE 




BZSUBTIP 




BZSVTIPTYPE 




BZBTRANS 




BZBRCV 




BZCTRANS 




BZCRCV 




BZTCBPTR 




BZLBTOMUX 


BZSUBTIP 


SUBRANGE 


BZTCBPTR 


BOBUFPTR 


BZLBTQMUX 


BOBUFPTR 



LINE NUMBER 

ACTIVE LCB TIME CHAIN 

WAIT COUNT 

NODE ID OF CS 

INPUT RETURN ADDRESS 

OUTPUT RETURN ADDRESS 

TIMAL APPENDAGE EXISTS 

OUTPUT QUEUED 

SM RESPONSE RECEIVED 

SM BEING TIMED OUT 

LINE TYPE 

HOST ORDINAL 

CURRENT CONFIGURATION STATE 

LINE SPEED 

NUMBER OF TCBS ATTACHED 

TERMINAL OUTPUT TIMED OUT 

TERMINAL INPUT TIMED OUT 

LINE DISABLED 

LINE STATE 

AUTO RECOGNITION . 

DIAGNOSTIC IN PROGRESS 

LAST WORK CODE 

TIP TYPE 

SUB TIP TYPE 

SAVE TIP TYPE 

BLOCKS TRANSMITTED 

BLOCKS RECEIVED 

CHARACTERS TRANSMITTED 

CHARACTERS RECEIVED 

TCB CHAIN 

LAST BUFFER TO MUX 

SET BY TIP ONLY IF AUTORECOGNIZED BY TIP 

POINTER TO FIRST TCB CHAINED ON THIS LINE 

LAST OUTPUT BUFFER SENT TO MUX (DEBUG USE) 



Figure 5-2. Line Control Block 
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Base part; 




1 
2 
3 
4 
5 
6 
7 
8 

9 

A 
6 

C 
* 

IF 



15 


14 


13 12 


11 


10 9 8 


7 


6 5 


4 


3 


2 


1 





BSCHAIN 


BSLCBP 




BSCA 




BSTA 




Fl 

1 


BSCODE 


BSHO 


F2 


BSTCLAS 


BSQPTR 




BSOWNER 


BSCN J 






BSLLCB 1 


F3 


BSABL 


F4 


BSOBL 


F5 


F6 


F7 


" 1 


* 


F9 


FA 


FB 


FC 


FD 


FE 


FF 


Gl 


G2 


BSSTIC 








VARIABLE PART 







ID 



Name 





BSCHAIN 




BSLCBP 




BSCA 




BSTA 


Fl 


BSSTOP 




BSCODE 




BSHO 


F2 


BSDEVTYPE 




BSTCLASS 




BSQPTR 




BSOHNER 




BSCN 




BSLLCB 


F3 


BSINOP 




BSABL 


F4 


BSTBRCCNF 




BSOBL 


F5 


BSLBTPROC 


F6 


BSACPIN 


F7 


BSACPOUT 


F8 


BSIPRl 


F9 


BSWAIT 


FA 


BSBSNLAST 


FB 


BSBSNCRNT 


FC 


BSTOTERM 


FD 


BSPARITY 


FE 


BSCHLEN 


FF 


BSPGWAIT 


Gl 


BSXPARENT 


G2 


BSHOTOGL 




BSSTIC 



Description 

POINTER TO NEXT TCB ON LINE 

LINE CONTROL BLOCK POINTER 

CLUSTER ADDRESS 

TERMINAL ADDRESS 

UPLINE STOP ODTSTANDING 

CODE SET IN USE 

HOST ORDINAL 

DEVICE TYPE 

TERMINAL CLASS 

QUEUE POINTER 

CONNECTION NUMBER 

LOGICAL LINK CONTROL BLOCK POINTER 

TERMINAL INOPERATIVE 

AVAILABLE BLOCK LIMIT 

TCB TO BE RECONFIGURED FLAG 

OUTSTANDING BLOCK LIMIT 

LAST BLOCK TYPE PROCESSED 

ACCEPT INPUT 

ACCEPT OUTPUT 

INPUT PRIORITY 

WAITING FOR INIT FLAG 

BSN OF LAST BACKED BLOCK 

BSN OF CRNT OUTPUT BLOCK 

TCB TO BE TERMINATED 

CHARACTER PARITY 

CHARACTER LENGTH 

PAGE WAIT SELECTED 

TRANSPARENT INPUT SELECTED 

HOST ORDINAL TOGGLE 

STATISTICS 



Figure 5-3. Terminal Control Block (1 of 3) 
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Printout cancelled by operator 

Fields accessible to the TIP ; 

Description 
next TCB chained on the line 



Field Name 
BSCHAIN 
BSCA 
BSTA 
BSSTOP 
BSGODE 
BSDEVTYPE 
BSTGIASS 
BSINOP 

*BSPAWTY 
*BSCHLEN 
*BSPGWAIT 
*BSXPARENT 



Type 
BOBUFPTR 
subrange 
subrange 
BOOLEAN 
subrange 
subrange 
subrange 
BOOLEAN 

subrange 
subrange 
BOOLEAN 
BOOLEAN 



cluster address 

terminal address 

true if STP block outstanding to host 

code set in use 

device type 

terminal class 

true if terminal inoperative SM sent to 
host by TIP, set and cleared by TIP 

parity in use 

character length 

set true if page wait in effect 

set true if next input is to be 
transparent, reset by TIP if processed 



*IVT variable fields in base 



IVT variable part! 



C 

D 

E 

F 

10 

11 

12 

ID 



15 


14 


13 


12 


11 10 


9 8 


7 6 5 4 3 2 


I 


BSPGWIDTH 


BSPGLENGTH 


BSCANCHR 


BSCNTRLCHAR 


BSUSRl 


BSUSR2 




Fl 


F2 


* 




BSXCNT 




F3 


F4 


F5 


F6 


F7 


F8 


BSXGHAR 






BSBSCHAR 


BSABTLINE 


BSCRIDLES 


BSLFIDLES 



Name 



Type 





BSPGWIDTH 


SR 




BSPGLENGTH 


SR 




BSCANCHAR 


C 




BSCNTRLCHAR 


C 




BSUSRl 


C 




BSUSR2 


G 


Fl 


BSXTO 


B 


F2 


BSXCHRON 


B 




BSXCNT 


SR 


F3 


BSCRCALC 


B 


F4 


BSLFCALC 


SR 


F5 


BSECHOPLX 


B 


F6 


BSINDEV 


B 



Description 

PAGE WIDTH 

PAGE LENGTH 

CANCEL CHARACTER 

CONTROL CHARACTER 

USER BREAK 1 CHARACTER 

USER BREAK 2 CHARACTER 

TRANSPARENT TIMEOUT 

TRANSPARENT DELIMITED BY CHAR 

TRANSPARENT INPUT CHARACTER COUNT 

CARRIAGE RETURN 

LINE FEED 

ECHOPLEX 

INPUT DEVICE 



Figure 5-3. Terminal Control Block (2 of 3) 
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VI 


BSOUTDEV 


SR 


F8 


BSAPL 


SR 




BSXCHAR 


C 




BSBSCHAR 


C 




BSABTLINE 


C 




BSCRIDLES 


C 




BSLFIDLES 


C 


SR = 


= subrange 




C = 


= CHAR 




B = 


= BOOLEAN 





OUTPUT DEVICE 

APL MODE 

TRANSPARENT TERMINATOR CHARACTER 

BACKSPACE CHARACTER 

ABORT LINE CHARACTER 

NUMBER OF IDLES AFTER CR 

NUMBER OF IDLES AFTER LF 



Figure 5-3. Terminal Control Block D of 3) 



The TIP can use seven of tlie possible types of command 
packets: 

• input 

• input after output 

■ output 

■ terminate input 

• terminate output 

• disable line 

• turn line around 

A sample format of one of these command packets is 
shown in figure 5-4. Each of the command packets are 
described in detail in the multiplex subsystem section. 



MUX LINE CONTROL BLOCK (MLCB) 

The MLCB is used to control the input and ouput of 
characters over a line, and to provide variable storage for 
input state processing. This table is never directly ac- 
cessed by the TIP. This description is for use in TIP de- 
bugging. Figure 5-5 shov/s the MLCB. 



Figure 5-8 shows the TIP type table. 



TERMINAL CHARACTERISTICS TABLE 

The terminal characteristics table is used for two pur- 
poses: 

■ To initialize the TCB with default values for IVT 
parameters 

• To initialize the TCB with default values for user 
calls to the multiplex subsystem. 

In the second case, the default values are overridden when 
the TIP specifies a value for that parameter in the com- 
mand packet. The run time TIP does not use the terminal 
characteristic table. However, the TIP writer must supply 
all the necessary initialization values at build time. These 
fields are defined in section 12. 

Figure 5-9 shows the terminal characteristics table. 



TEXT PROCESSING CONTROL BLOCK 

The TIP uses the text processing control block (TPCB) to 
pass information to the microassembly language text pro- 
cessor, and to the TIP's own text processing state pro- 
grams. These programs also pass data back to the 
OPS-level TIP through fields in the TPCB. Note that the 
TPCB is the only way data can be passed back and forth 
between the OPS-level TIP and the text processing 
modules of the TIP. The TIP sets up the TPCB prior to 
calling the text processor via PTTPINF. Figure 5-6 shows 
the TPCB. 

PORT TABLES 

The port tables (NAPORT) are multiword entries in an 
array which is indexed by the port index. The table is not 
accessible to the run time TIP, nor are its fields initial- 
ized by the TIP writer. However, during the debugging 
phase of a new TIP, it is often useful to observe the 
contents of the port table and to locate (through the port 
table) the multiplex LCBs that are being used for a 
particular line. 

The port table is shown in figure 5-7. 



CODE TRANSLATION TABLES 

The multiplex subsystem defines the format of a code 
translation table: it is a packed array of characters. The 
untranslated character is used as an index to find the 
translated character. Parity should be stripped from the 
untranslated character: this reduces the size of the table 
by fifty percent. 

Figure 5-10 shows the format of a code translation table. 



DYNAMIC BUFFERS 

The TIP accesses and manipulates buffers of various 
sizes. CCP offers four standard buffer sizes; 8, 16, 32, 
and 64 words long. The TIP accesses a buffer using a 
pointer word of BOBUFPTR type, as shown: 

VAR 

(bufptr) : BOBUFPTR; 
BEGIN 

WITH (bufptr) + DO 

BEGIN 



TIP TYPE TABLE 

The TIP type table contains those system parameters that 
are necessary to control a TIP. These fields are never ac- 
cessed by a TIP. The TIP writer must, however, initialize 
specified fields at build time. The fields to be initialized 
are defined in section 12. 



Data buffers may contain part or all of a message. In any 
system there is only one size of data buffer, though 
different systems may each have a different size data 
buffer. The standard system uses a 64 word buffer. TCBs 
also use data buffers, but the size and the content is 
controlled by the system (the TIP writer selects a size at 
build time, if his TIP is to be the only TIP in the system). 
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The TIP writer also uses a BOBUFPTR type pointer to 
access user-defined variables fields in the TCB. The over- 
lay type for naming TCB fields is BSTCB. A TCB is 
accessed as shown: 

VAR 

(tcbptr) : BOBUFPTR; 
BEGIN 

WITH (tcbptr) f. BSTCB DO 

BEGIN 



A chain of data buffers is shown in figure 5-11. The data 
buffers are defined in figure 5-12. 

SYSTEM CONSTANT DEFINITIONS 

Figure 5-13 defines the system constants that are avail- 
able for TIP use. 

SYSTEM TYPE DEFINITIONS 

Figure 5-14 defines the system types that are available 
for TIP use. 

SYSTEM VARIABLE DEFINITIONS 

The TIP can use a limited set of system variables as shown 
in figure 5-15. Most of these variables are used to 



interface to system procedures. 

SYSTEM ENGINEERING FILE WORK 
AREA 

The TIP makes entries to the system engineering work file 
when component failures are detected. The prototype of 
the engineering work file entry is built in the system 
global CNCEOVLY. This global is an array indexed by 
interrupt level. The TIP can issue a system engineering 
file entry at either the OPS level or at the Mux-2 level. 
Each entry in the array is structured for use by the TIP 
and by other already defined entries. The TIP writer de- 
fines field names for constructing each entry. After 
initializing the work area, the TIP calls PNCEFILE to 
issue the message. 

An example of TIP access to the engineering work file 
area is as follows: 

WITH (tcbpointer)+ .BSTCB DO 

WITH CNCEOVLY (LEVEL) DO 

BEGIN ' 

CNCECODE 

(line number) 

(cluster address) 

(terminal address) 

(device type) 

(terminal class) 

(error count) 
END; 

The engineering work file area is shown in figure 5-16. 



(error file entry code); 

(Icbpointer) .BZLINO; 

BSCA; 

BSTA; 

BSDEVTYPE; 

BSTCLASS; 

(occurrence count); 



INPUT or INPUT after OUTPUT: 



Fl 
F2 

F3 
F4 
F5 
F6 
F7 

F8 
F9 

FlO 



15 


14 


13 


12 


11 


10 


9 


8 


7 


6 


5 


4 3 2 


L 


NKCMD 


1 


NKLINO 1 










NKOBP 






Fl 


F2 


F3 


F4 


F5 


F6 


F7 


F8 


F9 


F 
10 


NKISTAI 


* 


F 
11 


* 






NKBLKL 














NKISPTA 






NKSCHR 


NKCHTl 1 


NKXLTA 1 



NKUOPl 

NKnOP2 

NKU0P3 

NKnOP4 

NKU0P5 

NK00P6 

NKU0P7 

NKU0P8 

NKMVB 

NKRPRT 



Figure 5-4. Command Packets (1 of 2) 
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OUTPUT: 


1 
2 




1 

Flags 



Fl 
F2 
F3 
F4 
F5 
F6 
F7 
F8 
F9 
FIO 

FU 



15 




8 


7 







NKCMD 


1 


HKLINO 


NKOBP 



15 




8 


7 







NKCMD 


1 


NKLINO 



Field Name 


Type 


NKCMD 


B08BITS 


NKLINO 


INTEGER 


NKOBP 


BOBUFPTR 


NKUOPl 


BOOLEAN 


NKU0P2 


BOOLEAN 


NKU0P3 


BOOLEAN 


NKU0P4 


BOOLEAN 


NKU0P5 


BOOLEAN 


NKU0P6 


BOOLEAN 


NKU0P7 


BOOLEAN 


NKU0P8 


BOOLEAN 


HKMVB 


BOOLEAN 


NKRPRT 


BOOLEAN 


NKISTAI 


B06BITS 


NKSCENBL 


BOOLEAN 


NKBLKL 


B012BITS 


HKISPTA 


INTEGER 


NKSCHR 


CHAR 


NKCHTl 


B08BITS 


NKLXTA 


INTEGER 



Definition 

COMMAND 

LINE NUMBER 

OUTPUT BUFFER POINTER 

USER OPTION FLAG 

USER OPTION FLAG 

USER OPTION FLAG 

USER OPTION FLAG 

USER OPTION FLAG 

USER OPTION FLAG 

USER OPTION FLAG 

USER OPTION FLAG 8 (MUX BIT 

MOVE USER BITS TO LCB FLAG 

STRIP PARITY FLAG 

INPUT STATE INDEX 

SPECIAL CHARACTER TO BE CHANGED 

BLOCK LENGTH COUNT 

INPUT STATE POINTER TABLE ADDRESS 

SPECIAL CHARACTER 

CHARACTER COUNT 1 VALUE (IF NOT = 0) 

TRANSLATE TABLE ADDRESS 



1 


(MUX BIT 


15) 


2 


(MUX BIT 


14) 


3 


(MUX BIT 


13) 


4 


(MUX BIT 


12) 


5 


(MUX BIT 


11) 


6 


(MUX BIT 


10) 


7 


(MUX BIT 


9) 



i) 



Figure 5-4. Command Packets (2 of 2) 
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15 14 13 12 


11 


10 


9 


8 


7 


6 


5 


4 3 2 1 







Fl 


F2 


F3 


F4 


F5 




F7 




NCOCHR 1 




F9 


F 
10 


F 
11 


NCTIME 


NCOBLCD 






NCOBP 






F 
12 


F 
13 


F 
14 


F 
15 


F 
16 


F 
17 


F 
18 


F 
19 


F 
20 


NCISTAI 




NCCNTL 


NCCNTl 




NCISPTA 




NCIBP 




F 
22 


F 
23 


F 
24 


F 
25 


F 
26 


F 
27 


F 
28 


F 
29 


F 
30 


F 
31 


F 
32 


NCCRCP 




NCSCHR 


NCIBFCD 




HCCRCS 








NCCNT2 








NCBLKL 




NCCXLTA - POINTER TO CODE TRANSLATE TABLE 




NCSCBA - POINTER TO FIRST BUFFER IN BLOCK 




NCBLCNT - NUMBER OF 
BUFFERS ALLOCATED 


NCSVWL - SAVED WORKLIST 




* 







1 

2 

3 

4 
5 
6 

7 

8 

9 
10 
11 
12 
13 

14 

15 

* reserved for CDC 



Flags 



Field 



Type 



Fl 


NCEOBL 


BOOLEAN; 


F2 


NCNXCCA 


BOOLEAN; 


F3 


NCLCT 


BOOLEAN; 


F4 


NCBCREQ 


BOOLEAN; 


F5 


NCOMFRO 


BOOLEAN; 


F7 


NCODDIN 


BOOLEAN; 




NCOCHR 


CHAR; 


F9 


NCSUPCHAIN 


BOOLEAN; 


FIO 


NCOBT 


BOOLEAN; 


Fll 


NCBZL 


BOOLEAN; 




NCTIME 


B05BITS; 




NCOBLCD 


B08BITS ; 




NCOBP 


BOBUFPTR; 


F12 


NCRINCH 


BOOLEAN; 


F13 


NCCAREC 


BOOLEAN; 


F14 


NCRIGHTC 


BOOLEAN; 


F15 


NCINFRO 


BOOLEAN 


F16 


NCNOXL 


BOOLEAN; 


F17 


NCRPRT 


BOOLEAN; 


F18 


NCSCF 


BOOLEAN; 


F19 


NCLASTCH 


BOOLEAN; 


F20 


NCEOSR 


BOOLEAN; 




NCISTAI 


B06BITS; 




NCCNTL 


B08BITS; 




NCCNTl 


B08BITS; 




NCISPTA 


INTEGER; 




NCIBP 


BOBUFPTR; 


F22 


NCUOPl 


BOOLEAN; 


F23 


NCU0P2 


BOOLEAN; 




Figure 5-5. 


Multiplex L 



Description 

END OF BLOCK FLAG 

NEXT OUTPUT CHAR AVAILABLE 

LAST CHARACTER TRANSMITTED 

BUFFER CHAINING REQUIRED 

OUTPUT MESSAGE IN PROGRESS 

ODD RECEIVE 

NEXT OUTPUT CHARACTER 

SUPPRESS BUFFER CHAINING 

GENERATE OBT 

RESET TIMER 

MLX TIMER 

LCD OF OUTPUT BUFFER 

OUTPUT BUFFER POINTER 

INPUT CHAR IN RIGHT BYTE 

CHARACTER RECEIVED FLAG 

LEFT/RIGHT SOURCE FLAG 

INPUT MESSAGE IN PROGRESS 

CODE TRANSLATE ACTIVE 

STRIP PARITY BIT 

TEXT PROCESS SUPPRESS CHAIN FLAG 

TEXT PROCESS SOURCE LCD REACHED 

TEXT PROCESS END OF SOURCE REACHED 

INPUT STATE PROGRAM INDEX 

CHARACTER COUNT ONE LIMIT 

CHARACTER COUNTER ONE 

INPUT STATE POINTER TABLE ADDRESS 

INPUT BUFFER POINTER 

USER OPTIONAL FLAG 1 

USER OPTIONAL FLAG 2 



5-10 
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F24 


NCU0P3 


F25 


NCU0P4 


F26 


NCH0P5 


F27 


NCU0P6 


F28 


NCU0P7 


F29 


NCU0P8 


F30 


NCETX 


F31 


NCMRTO 


F32 


NCCARR 




NCCRCP 




NCSCHR 




NCIBFCD 




NCCRCS 




NCCNT2 




NCBLKL 




NCCXLTA 




NCSCEA 




NCBLCNT 




NCSVWL 



BOOLEAN; USER OPTIONAL FLAG 3 

BOOLEAN; USER OPTIONAL FLAG 4 

BOOLEAN; USER OPTIONAL FLAG 5 

BOOLEAN; USER OPTIONAL FLAG 6 

BOOLEAN; USER OPTIONAL FLAG 7 

BOOLEAN; USER OPTIONAL FLAG 8 

BOOLEAN; DELAYED ETX WLE GENERATION FLAG 

BOOLEAN; MODEM RESPONSE TIMEOUT FLAG 

BOOLEAN; LINE CARRIER TYPE (1=CONTROLLED) 

B05BITS; CRC POLYNOMIAL 

CHAR; SPECIAL CHARACTER 

B08BITS; FCD OF INPUT BUFFER 

INTEGER; CRC ACCUMULATION 

B012BITS; CHARACTER COUNTER TWO 

B012BITS; CHARACTER COUNTER TWO LIMIT 

INTEGER; CODE TRANSLATE TABLE ADDRESS 

BOBUFPTR; FIRST BUFFER OF BLOCK ADDRESS 

B08BITS; BUFFERS ALLOCATED COUNTER 

B08BITS); SAVED WORKLIST VALUE 



Figure 5-5. Multiplex LCB (MLCB) (2 of 2) 



15 14 13 12 11 10 9 




1 
2 
3 

4 

5 
6 

7 

8 
9 
10 
11 
12 
13 

14 

15 

16 

17 

18 
19 



NCLCDFCD 1 


Fl 


* 


* 


* 


NCOBLCD 


NcsBP n 


F2 


* 


F3 


* 


F4 


F5 


F6 


F7 


F8 


* 


NCSTAI 1 


NCCNTL - CHARACTER NCCNTl - CHARACTER COUNTER 
COUNT LIMIT 


1 


NCSPTA - POINTER TO STATE PROGRAMS POINTER TABLE 


NCDBP - POINTER TO STATE PROGRAMS TABLE 


F9 


F 
10 


F 
11 


F 
12 


F 
13 


F 
14 


F 
15 


F 
16 


F 
17 


F 

18 


F 
19 


NCCRCP 


NCSCHR 


NOBFCD 1 


NCCRCS J 


* 


NCCNT2 


* 


NCBLKL 


NCCXLTA - POINTER TO CODE TRANSLATE TABLE 


NCSCBA - POINTER TO FIRST BUFFER IN BLOCK 


NCBLCNT - NUMBER OF BUFFERS 
ALLOCATED 




1 


* 


F 
20 


* 


F 
21 


— 


NCFSBA - FIRST STORAGE BUFFER ADDRESS 


RESERVED FOR TIP USAGE 1 



* reserved for CDC 

Figure 5-6. Text Processing Control Block (TPCB) (1 of 2) 
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Flags 


Field 


Type 




NCLCDFCD : 


INTEGER 


Fl 


NCSUPCHAIN : 


BOOLEAN; 




NCCBLCD ! 


BLBBITS; 




NCSBP : 


BOBUFPTR; 


F2 


NCCCRB : 


BOOLEAN; 


F3 


NCRIGHTC : 


BOOLEAN; 


F4 


NCNOXL ; 


BOOLEAN; 


F5 


NCRPRT 


BOOLEAN; 


F6 


NCSCF : 


BOOLEAN; 


F7 


NCLASTCH 


BOOLEAN; 


F8 


NCEOSR 


BOOLEAN; 




NCSTAI 


B06BITS ; 




NCCNTL 


B08BITS; 




NCCNTl 


B08BITS ; 




NCSPTA 


INTEGER; 




NCDBP 


BOBUFPTR; 


F9 


NCUOPl 


BOOLEAN; 


FIO 


NCU0P2 


BOOLEAN; 


Fll 


NCU0P3 


BOOLEAN; 


F12 


NCU0P4 


BOOLEAN; 


F13 


NCUOPS 


BOOLEAN; 


F14 


NCU0P6 


: BOOLEAN; 


F15 


NCU0P7 


• BOOLEAN; 


F16 


NCUOPS 


: BOOLEAN; 


F17 


NCETX 


: BOOLEAN; 


F18 


NCMRTO 


: BOOLEAN; 


F19 


NCCARR 


: BOOLEAN; 




NCCRCP 


: B05BITS; 




NCSCHR 


: CHAR; 




NCBFCD 


: B08BITS; 




NCCRCS 


: INTEGER; 




NCCNT2 


: B012BITS; 




NCBLKL 


: B012BITS; 




NCCXLTA 


: INTEGER; 




NCSCBl 


: BOBUFPTR; 




NCSLCNT 


: B08BITS ; 


F20 


— 


CHAR 


F21 


— 


CHAR 



Description 

FCD AND LCD OF SOURCE BUFFER 
SUPPRESS BUFFER CHAINING 
LCD OF OUTPUT BUFFER 

SOURCE BUFFER POINTER. 

DEST. CHAR IN RT. BYTE 
LEFT/RIGHT SOURCE FLAG 
CODE TRANSLATE ACTIVE 
STRIP PARITY BIT FLAG 
TEXT PROCESSOR SUPPRESS CHAIN FLAG 
TEXT PROCESSOR SOURCE LCD REACHED 
TEXT PROCESSOR END OF SOURCE REACHED 

STATE PROGRAM INDEX. 
CHARACTER COUNT LIMIT 
CHARACTER COUNTER ONE 

STATE POINTER TABLE ADRS. 

DESTINATION BUFFER PNTR. 
USER OPTIONAL FLAG 1 
USER OPTIONAL FLAG 2 
USER OPTIONAL FLAG 3 
USER OPTIONAL FLAG 4 
USER OPTIONAL FLAG 5 
USER OPTIONAL FLAG 6 
USER OPTIONAL FLAG 7 
USER OPTIONAL FLAG 8 
USER OPTIONAL FLAG 9 
MODEM RESPONSE TIMEOUT 
LINE CARRIER TYPE (1=C0NTR0LLED) 
CRC POLYNOMIAL 
SPECIAL CHARACTER 

BUFFER FCD. 
CRC ACCUMULATION 
CHARACTER COUNTER TWO 
CHARACTER COUNTER TWO LIMIT 
CODE TRANSLATE TABLE ADDRESS 
FIRST BUFFER OF BLOCK ADDRESS 
BUFFERS ALLOCATED COUNTER 
CURRENT SOURCE CHARACTER 
RIGHT SOURCE CHARACTER 



Figure 5-6. Text Processing Control Block (TPCB) (2 of 2) 
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Fl 


F2 


F3 


F4 


F5 


NALTYP 




NASPILL 


1 


1 


NALCBP 1 


2 


NAOBTCMD 


F6 


F7 


F8 


F9 


NAMSI 





3 






NAMSPTA 






4 


Cbl 


Cb2 


5 


Cb3 


Cb4 


6 


NASTAT ] 


7 






* 








Fl 


NAION 












F2 


NAOON 












F3 


NAISON 












F4 


NALCBUP 












F5 


NAISR 












F6 
F7 


NANDCD 
NAMTD 












F8 


NAWAIT 












F9 


NAOVFE 























Cbl CLA command byte 1 

Cb2 CLA command byte 2 

Cb3 CLA command byte 3 

Cb4 CLA conmand byte 4 



Name 


Type 


Description 


NAION 


: BOOLEAN; 


INPUT ON FLAG 


NAOON 


: BOOLEAN; 


OUTPUT ON FLAG 


NAISON 


: BOOLEAN; 


INPUT SUPERVISION 


NALCBUP 


: BOOLEAN; 


LCB ASSIGNED FLAG 


NAISR 


BOOLEAN; 


CLA STATUS PENDING 


NALTYP 


B05BITS; 


LINE TYPE 


NAHABDER 


BOOLEAN; 


HARD ERROR IN PROGRESS 


NASPILL 


B05BITS ; 


CLA STATUS COUNT 


NALCBP 


NOLCBP; 


POINTER TO MUX LCB 


NAOBTCMD 


B08BITS ; 


CLA TURNAROUND COMMAND 


NANDCD 


BOOLEAN; 


DCD DROPPED 


NAMTO 


BOOLEAN; 


MODEM TIMEOUT IN PROGRESS 


NAWAIT 


BOOLEAN; 


FLAG FOR FIRST OVFL. TIMEOUT 


NAOVFE 


BOOLEAN; 


FIRST STATUS OVFL- WL RCV 


NAMSI ; 


B04BITS; 


MODEM STATE INDEX 


NAMSPTA 


INTEGER; 


MODEM STATE POINTER TABLE 


NAFCCST : 


NFCCSE; 


CLA COMMAND WORDS 


NASTAT : 


INTEGER; 


CLA STATUS 



Figure 5-7. Port Table 
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Word 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 



15 14 13 12 11 10 9 8 7 
Fl F2 * F3 BJIVTSIZE F4 



Flag 



Field 



F5 



BJLISTIX 



BJDFTC 



BJPTIMRTN 



BJETIMETN 



BJJFTD 



BJFDT 



BJJAT 



BJAT 



BJTPMUX2 



BJTEMUX2 



BJTCBPINIT 



BJTCBEINIT 



BJTXTPAGE 



BJTXTENT 



Type 



Fl 


BJOBT 


BOOLEAN; ( 


F2 


BJBZL 


BOOLEAN; 1 




BJIVTSIZE 


B04BITS ; 1 


F4 


BJTCBSIZE 


BOBUFSIZES; 


F5 


BJQTYPE 


BOOPTYPES; 




BJLISTIX 


BOWKLSTS; 1 




BJDFTC 


NOTCLASS; 




BJPTIMRTN 


INTEGER: 




BJETIMRTN 


INTEGER; 




BJJFDT 


DDFDTPTR; 




BJFDT 


DDFDTPTR; 




BJJAT 


dfatptr; 




BJAT 


DFATPTR; 




BJTPMUX2 


INTEGER; 




BJTEMUX2 


INTEGER; 




BJTCBPINIT 


INTEGER; 




BJTCBEINIT 


INTEGER; 




BJTXTPAGE 


INTEGER; 




BJTXTENT 


INTEGER; 



Description 

GENERATE OUTPUT BUFFER TRANSMITTED FLAG 

RESET TIMER FLAG ON OBT 

NO. WORDS IN TCB/TCT IVT 

TCB BUFFER SIZE 

TYPE OF QUEUE FOR DATA 

WORKLIST INDEX 

DEFAULT TERM CLASS FOR PTENABL 

TIP TIMAL ROUTINE - PAGE ADDR 

TIP TIMAL ROUTINE - ENTRY ADDR 

TCB FIELD DESCRIPTOR TABLE ADDR 

LCB FIELD DESCRIPTOR TABLE ADDR 

TCB ACTION TABLE ADDRESS 

LCB ACTION TABLE ADDRESS 

TIP LEVEL TWO PAGE ADDRESS 

TIP LEVEL TWO ENTRY ADDRESS 

TCB INIT ROUTINE PAGE 

TCB INIT ROUTINE ENTRY 

TEXT PROCESSING PAGE 

TEXT PROCESSING ENTRY 



Figure 5-8. TIP Type Table 
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1 

2 
3 
4 
5 
6 
7 
8 
9 

10 

11 
12 



Flag 



15 


14 


13 


12 


11 10 


9 


8 


7 6 5 


4 


3 2 10 


NJISPTA 




NJCXLTA 




NJCNTl 


NJSYNC 




NJCRCP * 


NJIBFCD 




NJBLKL 


NJTIPTY 




Fl 


F2 


F3 


F4 


F5 


* 




NJPGWIDTH 


NJPGLENGTH 




NJCANCHAR 


NJCNTRLCHAR 




NJUSRl 


NJUSR2 




F6 


F7 


* 


NJXCNT 




F8 


F9 


F 
10 


F 
11 


F 
12 


F 
13 


NJXCHAR 




NJBSCHAR 


NJABTLINE 




NJCRIDLES 


NJLFIDLES 





Field 



Type 





NJISPTA 


: INTEGER; 




NJCXLTA 


: INTEGER; 




NJCNTl 


: B08BITS ; 




NJSYNC 


: B08BITS; 




NJCPCP 


: BOS BITS; 




NJIBFCD 


: B08BITS; 




NJBLKL 


: B012BITS; 




NJTIPTY 


: NOTIPTY; 


Fl 


NJPARITY 


: B02BITS ; 


F2 


NJCHLEN 


: B02BITS; 


F3 


NJPARTYPE 


: B02BITS ; 


F4 


NJPGWAIT 


: BOOLEAN; 


F5 


NJXPARENT 


: BOOLEAN; 




NJPGWIDTH 


: B08BITS; 




NJPGLENGTH 


: B08BITS; 




NJCANCHAR 


CHAR; 




NJCNTRLCHAR 


CHAR; 




NJUSRl 


CHAR; 




NJUSR2 


CHAR; 


F6 


NJXTO 


BOOLEAN; 


F7 


NJXCHRON, 






NJXCNT ; 


B012BITS; 


F8 


NJCRCALC : 


BOOLEAN; 


F9 


NJLFCALC : 


BOOLEAN; 


FIO 


NJECHOPLX : 


BOOLEAN; 


FU 


NJINDEV : 


BOOLEAN; 


F12 


NJOUTDEV : 


B02BITS; 


F13 


NJAPL : 


B02BITS; 




NJXCHAR : 


CHAR; 




NJBSCHAR : 


CHAR; 




NJABTLINE : 


CHAR; 




NJCRIDLES : 


B08BITS; 




NJLFIDLES : 


B08BITS); 



Description 

INPUT STATES PTR TBL ADDRESS 

CODE TRANSLATE TABLE ADDR 

INPUT CHARACTER COUNT 1 

SYNC CHARACTER 

CRC POLYNOMIAL INDEX 

FCD OF FIRST BUFFER 

BLOCK SIZE 

TIP TYPE 

PARITY 

CHARACTER LENGTH 

PARITY TYPE FOR ASYNC TIP 

PAGE WAIT MODE 

TRANSPARENT INPUT MODE 

PAGE WIDTH 

PAGE LENGTH 

CANCEL INPUT LINE CHAR 

CONTROL CHARACTER 

USER BREAK ONE 

USER BREAK TWO 

TIMEOUT IS EXPECTED DELIMITER 

XPT CHAR IS A DELIMITER 

TRANSPARENT CHARACTER COUNT 

CR IDLE CNT TO BE CALCULATED 

LF IDLE CNT TO BE CALCULATED 

ECHOPLEX MODE 

INPUT DEVICE (F=KB, T=PT) 

OUTPUT DEVICE (PRT,DISPLAY,PT) 

APL (0=NO,1=YES,2=SPECIAL) 

TRANSPARENT DELIMITER CHAR 

BACKSPACE CHARACTER 

ABORT OUTPUT LINE CHARACTER 

COUNT OF IDLES AFTER CR 

COUNT OF IDLES AFTER LF 



Figure 5-9. Terminal Characteristics Table 
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15 



8 7 



TRANSLATE 


1 TRANSLATE 














1 TRANSLATE 


1+2 TRANSLATE 






254 TRANSLATE 


255 TRANSLATE 



Figure 5-10. Example of a Code Translate Table 



USER POINTER 



z 



BCCHAINS QCHN 



D 



BSCHAINS 



DBUFUEM.TH 



) 



D 



EXAMPLE SHOWS DATA BUFFERS 



Figure 5-11. Queue of Chained Buffers 
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Word 15 


1 

2 

3 



8 7 



BFLCD 


BFFCD 1 


FLAG WORD 


BCCHAINS (QCHN) 






BCCHAINS (N+1) 



where flags are as follows: 



15 


14 


13 


12 


11 


10 


9 


8 


7 


6 


5 


4 


3 


2 


1 





Fl 




F2 




F3 




F4 


F5 




F6 


F7 


F8 


1 



where ; 

Fl = BFEOTFLG - set by input state instruction, used for data sent 
across coupler, not maintained by TIP 

F2 = BFSUPCHAIN - set to inform firmware that buffer is of 

non-standard length; that is, don't look for chain word 

F3 = BFINTBLK - set to inform TIP that block did not originate in 
host, stops BIP from sending an acknowledge to host 

F4 = BFPEEM - set to indicate an array being used as a buffer, used 
to inhibit any attempt to release buffer 

F5 = BFLNKQ - set to indicate a valid address is present in the queue 
word 

F6 = BFSP7 - TIP defined, can be set by input state instruction 

F7 = BFSP8 - TIP defined, can be set by input state instruction 

F8 = BFSP9 - TIP defined, can be set by input state instruction 

All other flag bits should not be used by the TIP. 

Field Name Type Purpose 

BFLCD, BFFCD SUBRANGE Specify the last character and the first 

character of data in the buffer. They are 
of subrange type. 

BCCHAINS BOBUFPTR Array for accessing the queue and chain 

words, indeK beginning with 1. 

Alternate types for buffer structure; 



BFDATAC 



BSTCB 



BUNT 



CHAR 



BOTCB 



Character array for accessing each 8-bit 
character in buffer, beginning with zero. 

Packed record used for accessing TCBs which 
are assigned to data buffers. 



INTEGER Array for accessing each word in buffer, 
usually to clear fields initially, index 
beginning with 1. 

Figure 5-12. Data Buffers (1 of 2) 
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Constants available for buffer manipulation : 

QCHN INTEGER Selects the word in a data buffer used for 

queuing. 

DATA INTEGER Character displacement for first data 

character in first buffer of a chain. 

KBYTE INTEGER Character displacement for first data 

character in subsequent buffers of a chain. 

BTPT INTEGER Character displacement of the block type 

byte of a message. 

DBC INTEGER Character displacement of the data block 

clarifier byte of a message. 

DBUFLENGTH INTEGER Length of data buffer in words. 

JILASTCHAR INTEGER Last usable character in a data buffer. 

B0S32 INTEGER 32 

B0S64 INTEGER 64 

BETPSIZE INTEGER Pointer to control tables for buffers used 

for TPCB. 

TPBUFLENGTH INTEGER Size of TPCB buffer in characters. 



Figure 5-12. Data Buffers (2 of 2) 



MULTIPLEX SUBSYSTEM COMMANDS 
THESE ARE COMMANDS ISSUED TO THE MUX COMMAND DRIVER 



NKINPT 


= 


6; 


INPUT 


NKDOUT 


= 


7; 


DIRECT OUTPUT 


NKINOUT 


— 


9; 


INPUT AFTER OUTPUT 


NKENDIN 


= 


$A; 


TERMINATE INPUT 


NKENDOUT 


= 


$B; 


TERMINATE OUTPUT 


NKDISL 


= 


$C; 


DISABLE LINE 


NKCLRL 


= 


$D; 


CLEAR LINE 


NKCONTROL 


= 


$E; 


CONTROL 



* 



* 

* EVENT WORK CODES * 

* THESE WORK CODES APPEAR IN THE WORK CODE FIELD OF THE EVENT PACKET RETURNED TO * 

* THE EVENT WORKLIST QUEUE. THEY SPECIFY THE NATURE OF THE INFORMATION CONTAINED * 

* IN SAID PACKET. CODE VALUES OF 1 THROUGH $1E ARE RESERVED FOR MUX USE EXCLUSIVELY * 

* * 



OUTPUT BUFFER TRANSMITTED 
BUFFER THRESHOLD CHANGED 
FRAIMING ERROR STATUS 
CHARACTER TIMEOUT 
INPUT TERMINATED 
OUTPUT TERMINATED 
ASYHC BREAK DETECTED 
HARD ERSOR 



MMOBUX 


= 


2; 


MMBUTCH 


= 


3; 


MMFES 


= 


8; 


MMCHOUT 


= 


9; 


HMINEND 


= 


$c; 


NMOTEND 


= 


$D; 


MMBREAK 


= 


$e; 


MMHARDERR 


= 


$F5 



Figure 5-13. System Constants Used by the TIP (1 of 8) 
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************************************************************ 

* 

* 

* 



LINE SPEED INDEX TABLE (ASYNCHRONOUS) 



************** 
* 
* 
* 



INDEX 






BAUD RATE 


N0800 


= 


0; 


800 


NO 110 


= 


1; 


110 


NO 134 


= 


2; 


134.5 


NO 150 


=! 


3; 


150 


N0300 


= 


4; 


300 


N0600 


= 


5; 


600 


NO 1200 


= 


6; 


1200 


N02400 


= 


7; 


2400 


N04800 


=5 


8; 


4800 


N09600 


= 


9; 


9600 


NODIAG 


= 


10; 


DIAGNOSTICS CLASS 



KEY 



NOBCD 


= 


1; 


NOASCII 


= 


2; 


N0MODE4C 


= 


3; 


NOTYPEPAPL 


= 


3; 


NOBITPAPL 


= 


4; 


NOEBCDAPL 


== 


5; 


NOEAPLAPL 


= 


6; 


NOCORR 


= 


7; 


NOCORAPL 


= 


8; 


NOXBCD 


= 


9; 



* 
CODE SET KEYS * 

* 
************************************************^ 



CODE SET 

BCD - MODE 4A BCD 

ASCII - ASCII FOR ASYNC OR MODE 4A ASCII 

MODE 4C 

TYPEWRITER-PAIRED APL-ASCII 

BIT-PAIRED APL-ASCII 

EBCD 

EBCD APL 

CORRESPONDENCE 

CORRESPONDENCE APL 

EBCDIC 



****** 

* 

* 

* 

********************************* 

NICON 

NICR 

NILP 

NIC? 

NIPLOT 

NIINTDEV 



DEVICE TYPE 



*********************** 
* 
* 

* 



0; 


CONSOLE 


1; 


CARD READER 


2; 


LINE PRINTER 


3; 


CARD PUNCH 


4; 


PLOTTER 


7; 


INTERNAL DEVICE 



****** 

* 
* 
* 



**************************************************************************** 

* 

MODEM CONTROL STATES * 

* 



MSTIDL 



= 4; STATE 4, LINE IDLED 



Figure 5-13. System Constants Used by the TIP (2 of 8) 
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OPS LEVEL WORKCODES 
THE FOLLOWING WORKCODES ARE USED FOR BASE SYSTEM, 
TIP, SVM, AND APPLICATION FUNCTION. 

*************** 
—SYSTEM WORKCODES FOR TIP- 



AOHARDERR 


= $0F; 


HARD ERROR 


- 


FROM MUX SUBSYSTEM 


AOTIMEOUT 


= $10; 


LINE TIMER EXPIRED - 


FROM LCB SCAN 


AOQUEOUT 


= $11; 


OUTPUT IN QUEUE 


FROM INTERNAL P. 


AOSMEN 


= $12; 


ENABLE LINE 


- 


FROM LINE INIT. 


AOSMDA 


= $13; 


DISABLE LINE 


- 


FROM SVM 


AOSMTCB 


= $14; 


TCB BUILT 


- 


FROM SVM 


AOSMDLTCB 


= $15; 


DELETE TCB 


- 


FROM SVM 


AOSMRCTCB 


= $16; 


RECONFIGURE TCB 


FROM SVM 






— MISCL.— 






AOBREAK 


= $19; 


DOWNLINE BREAK 


- FROM SVM 


AOOBUX 


= $1A; 


OUTPUT BUFFER 


XMIT 


- FROM TIP TO TIP 


- 


-WORKCODES TO THE SERVICE MODULE— 


COLINOP 


= $20; 


LINE OPERATIONAL 


- FROM TIP 


COLNINOP 


= $21; 


LINE INOPERATIVE 


- FROM TIP 


COLNDA 


= $22; 


LINE DISABLED 




- FROM TIP 


CODLTCB 


= $23; 


TCB DELETED 




- FROM TIP 


CORCTCB 


= $2C; 


TERMINAL RECONFIGD 


- FROM TIP 


—TIP 


GENERATE! 


WORKCODES FROM 


INPUT 


STATES— 


AOWKl 


= $21; 


TIP WOHKCODE 


1 , 




A0WK2 


= $22; 


TIP WORKCODE 


2 




A0WK3 


= $23; 


TIP WORKCODE 


3 




A0WK4 


= $24; 


TIP WORKCODE 


4 




A0WK5 


= $25; 


TIP WORKCODE 


5 




A0WK6 


= $26; 


TIP WORKCODE 


6 




A0WK7 


= $27; 


TIP WORKCODE 


7 




A0WK8 


= $28; 


TIP WORKCODE 


8 




A0WK9 


= $29; 


TIP WORKCODE 


9 




AOWKIO 


= $2A 


TIP WORKCODE 


10 




AOWKll 


= $2B 


TIP WORKCODE 


11 




AOWKl 2 


= $2C 


TIP WORKCODE 


12 




AOWKl 3 


= $2D 


TIP WORKCODE 


13 




A0WK14 


= $2E 


TIP WORKCODE 


14 




AOWKl 5 


= $2F 


TIP WORKCODE 


15 




A0WK16 


= $30 


TIP WORKCODE 


16 




A0WK17 


= $31 


TIP WORKCODE 


17 




A0WK18 


= $32 


; TIP WORKCODE 


18 




AOWKl 9 


= $33 


; TIP WORKCODE 


19 




AOWK20 


= $34 


f TIP WORKCODE 


20 




A0WK21 


= $35 


; TIP WORKCODE 


21 




A0WK22 


= $36 


; TIP WORKCODE 


22 




A0WK23 


= $37 


; TIP WORKCODE 


23 




A0WK24 


= $38 


; TIP WORKCODE 


24 




AOWK25 


= $39 


; TIP WORKCODE 


25 




A0WK26 


= $3A 


; TIP WORKCODE 


26 




AOWK27 


= $3B 


; TIP WORKCODE 


27 




A0WK28 


= $3C 


; TIP WORKCODE 


28 




A0WK29 


= $3D 


; TIP WORKCODE 


29 




A0WK30 


= $3E 


; TIP WORKCODE 


30 




A0WK31 


= $3F 


; TIP WORKCODE 


31 
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BLOCK PROTOCOL CONSTANTS 



HTBLK 


= $1 


BLOCK TYPE 


HTMSG 


= $2 


MESSAGE TYPE 


HTBACK 


= $3 


BACK TYPE 


HTCMD 


= $4 


COMMAND TYPE 


HTBREAK 


= $5 


BREAK TYPE 


HTSTOP 


= $6 


STOP TYPE 


HTSTRT 


= $7 


START TYPE 


HTRESET 


= $8 


RESET TYPE 


HTINIT 


= $9 


INITIALIZE TYPE 



BLOCK WORD DEFINITIONS 



QCHN 



3; WORD INDEX FOR QUEUE 

* 

TERMINAL CLASS * 



****************** 

* 

* 

* ^ 

*******************************************ft*********4**4****^i.*jtjt*j^^^^4.^j^^^^^^jj.^^^jt^^j^ 



NOTMLIA 


= 


0; 


MLIA 






N0M33 


= 


1; 


ASYNC 


- 


M33,M35,M37,M38 


N0713 


= 


2; 




- 


CDC 713 


N0M1240 


= 


3; 




- 


MEMOREX 1240 


N02741 


= 


4; 




- 


IBM 2741 


N0M40 


= 


5; 




- 


M40 


NOH2000 


= 


6; 




- 


HAZELTINE 2000 


N0751 


= 


7; 




- 


CDC 751-1 


N0T4014 


= 


8; 




- 


TEKTRONIX 4014 


NOHASP 


= 


9; 


HASP 






N02000T 


= 


10; 


MODE 4 


- 


200UT 


N0214 


= 


u; 




- 


214 


N07U 


= 


12; 




- 


711-10 


N0714 


= 


13; 




- 


714 


N0731 


= 


14; 




- 


731 


N0734 


= 


15; 




- 


734 



NOHDLC 


= 0; 


Nl ASYNC 


= 1; 


N1M4 


= 2; 


NIHASP 


= 3; 


N0780 


= 4; 


NOHLIA 


= 5; 


NOCONSOLE 


= 6; 


NOCOUPLER 


= 7; 


NOLINIT 


= 8; 


NOOLDIAG 


= 9; 



******************************************«;jt^jt^« 

* 

TIP TYPES * 



HDLC LIP 

ASYNC TIP 

MODE 4 TIP 

HASP TIP 

2780/3780 

MLIA ERROR HANDLER 

NPU CONSOLE 

CYBER COUPLER 

LINE INITIALIZER 

ON-LINE DIAGS **LAST TIP TYPE ALWAYS** 
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'fricirit'irick'tt 

* 
* 
* 



SUB TIP TYPES 



NOASllO 


= 


1; 


110 BAUD ASCII 


K0AS150 


= 


2; 


150 BAUD ASCII 


N0AS300 


= 


3; 


300 BAUD ASCII 


N0E2741 


ss 


4; 


2741 EBCD 


N0C2741 


= 


5; 


2741 CORRES 


N0M4A 


= 


1; 


M0DE4A 


N0M4C 


= 


2; 


M0DE4C 



* 

* INPUT STOPPED REASON CODES 

* 



B9SIRESP0NSE 


= 0; 


STOP INPUT RESPONSE 


B9N0TREADY 


= 1; 


INPUT DEVICE NOT READY 


B9CSLIP 


= 2; 


CARD SLIP ERROR 


B9E0I 


= 3; 


EOI IN INPUT DATA 


B9 INTACT 


= 4; 


INTERACTIVE INTERRUPT 



* 
* 
* 




L 1 ■ ■ .* ■> ■■■■t.-t. ■■■ 


COMMAND PFC/SFC 




D8CTRL 


= $01 


****** ************ *** ***** w fc'X'xyetc'rc^ 

CONTROL PFC 




D9START 


= $05 


START INPUT SFC 




D9ST0P 


= $06; 


STOP INPUT SFC 




D9STPD 


= $07; 


INPUT STOPPED SFC 




D9DEF 


= $04; 


DEFINE TERMINAL CHARACTERISTICS 



******* *****J»***JHt**********************-t*A***********************************<^ 

* * 

* 

* 

************** 



UPLINE BREAK REASON CODES 



B9USR1 


= 1; 


USER BREAK 1 


B9USR2 


= 2; 


USER BREAK 2 


B90DEVN0TRDY 


= 3; 


OUTPUT DEVICE NOT READY 


B9F0RMAT 


= 4; 


BAD BLOCK FORMAT 



UPLINE STOP REASON CODES 



************************************** 



B9TBnSY = 1; 
B9TFAILURE = 2; 
B9BINTERRUPT = 3; 



TERMINAL BUSY 
TERMINAL FAILURE 
BATCH INTERRUPT 

*************** 



C6L0PER 
C6LIN0P 
C61JS10RING 



LINE STATUS RESPONSE CODES 

0; LINE OPERATIONAL 
4; LINE INOPERATIVE 
5; NO RING INDICATOR 



*************** 
* 
* 
* 
************* 
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* * 

* IVT BUILD PARAMETERS * 

* * 



B7AIMAX 
B7PWDEF 



= 20; 
= 140; 



MAX AUTO INPUT PARAMETERS 
DEFAULT INPUT BLOCK SIZE 



IVT PARITY OPTIONS 



* 
* 
* 

****** 



B7ZER0 


= 


ZERO PARITY 


B70DD 


= 1 


ODD PARITY 


B7EVEN 


= 2 


EVEN PARITY 


B7N0NE 


= 3 


NO PARITY 



***************************************i*.ii,*5tjtijtj^4^^^^^i.^^^^^^^^^^^^^^^^^^j^^^^^^^^^^^^ 

* * 

* IVT APL OPTIONS * 

* * 



************icic*icicirk********ic-k*******i!i,-k***ic**-kirk*irk* 



B8APLN0 


= 0; 


APL MODE = NO 


B8APLYES 


= 1; 


APL MODE = YES 


B8APLSPEC 


= 2; 


APL MODE = SPECIAL 



***********4************************************A*******************4*i*i****^t***^t*4^^ 
* 



IVT OUTPUT DEVICE OPTIONS 



*********************** 



B8PRNTR 


= 0; 


PRINTER 


B8DISPLAY 


= 1; 


DISPLAY 


B8PTAPE 


= 2; 


PAPER TAPE 



IVT MISCELLANEOUS CONSTANTS 



B8N0PAGING 


= 0; 


PAGE WIDTH = (NO PAGING) 


B70DDPAR 


= 0; 


BSPARITY = ODD PARITY 


B7N0PAR 


= 1; 


BSPARITY = NO PARITY 


B7EVPAR 


= 2; 


BSPARITY = EVEN PARITY 



******************** ************************A*AA-*****.st***VtVt*************************** 

* * 

* TVT rHARArTKR rvKlTTHTTTnNS * 



IVT CHARACTER DEFINITIONS 
THE FOLLOWING CHARACTERS ARE DEFINED FOR THE INTERACTIVE 
VIRTUAL TERMINAL 



-FORMAT EFFECTORS— 



I9FSS 


= $20; 


FE 


I9FDS 


= $30; 


FE 


I9FTS 


= $2D; 


FE 


I9FNS 


= $2B; 


FE 


I9FRS 


= $2A; 


FE 


I9FPE 


= $31; 


FE 


I9FNA 


= $20; 


FE 


I9PSS 


= $2E; 


FE 


I9PNS 


= $2F; 


FE 



SINGLE SPACE 

DOUBLE SPACE 

TRIPLE SPACE 

START OF CURRENT LINE 

TOP OF FORM 

HOME CURSOR AND CLEAR 

NO ACTION 

POST PRINT SINGLE SPACE 

POST PRINT START OF CURRENT LINE 
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I9LF 
I9CR 
I9US 



—CONTROL CODES— 

= $0A; LINE FEED 

= $0D; CARRIAGE RETURN 

= $1F; LOGICAL LINE SEPARATOR 



iWt****A***********************************<rilr******************************* 



BVT CHARACTER DEFINITIONS 
THE FOLLOWING CHARACTERS ARE DEFINED FOR THE 
BATCH VIRTUAL TERMINAL 



B9BVT = $FF; BVT ESCAPE CODE 
—MODE CHANGE- 



MODE CHANGE - NONE 
MODE CHANGE - 029 
MODE CHANGE - 026 
MODE CHANGE - OTHER 



— INFORMATION SEPARATORS— 

$0A; END OF MEDIA 
$0B; END OF RECORD 
$0C; END OF INFORMATION 

— COMPRESSED BLANKS— 



B9MCN0 


= $00; 


B9MC29 


= $01; 


B9MC26 


= $02; 


B9MC0T 


= $03; 



B9E0M 
B9E0R 
B9E0IN 



B9CB02 
B9CB31 



B9CZ02 
B9CZ15 



B9RC02 
B9RC79 



B9SLEN 
B9SL01 
B9SL63 



$12; 
$2F; 



2 COMPRESSED BLANKS 
31 COMPRESSED BLANKS 



—COMPRESSED ZEROES— 



$32; 
$3F; 



2 COMPRESSED ZEROES 
15 COMPRESSED ZEROES 



—REPLICATION COUNT— 

$42; 2 REPEATED CHARACTERS 
$8F; 79 REPEATED CHARACTERS 

— STRING LENGTH— 

$90; INDETERMINATE LENGTH 
$91; STRING OF LENGTH 1 
$CF; STRING OF LENGTH 63 



-FORMS CONTROL- 









PREPRINT 


P0£ 


5TPRIN1 


B9FCS1 


= 


$E0; 


SPACE 1 


NO 


SPACE 


B9FCS2 


= 


$E1- 


SPACE 2 


NO 


SPACE 


B9FCS3 


= 


$E2 


SPACE 3 


NO 


SPACE 


B9FCSS 


= 


$E3 


SUPPRESS SPACE 


NO 


SPACE 


B9FCPE 


= 


$E4 


PAGE EJECT 


NO 


SPACE 


B9FCBP 


s 


$E5 


BOTTOM OF PAGE 


NO 


SPACE 


B9FCC6 


= 


$E6 


CHANNEL 6 


NO 


SPACE 


B9FCC5 


= 


$E7 


CHANNEL 5 


NO 


SPACE 


B9FCC4 


= 


$E8 


CHANNEL 4 


NO 


SPACE 


B9FCC3 


= 


$E9 


CHANNEL 3 


NO 


SPACE 


B9FCC2 


= 


$EA 


CHANNEL 2 


NO 


SPACE 


B9FC11 


= 


$EB 


CHANNEL 11 


NO 


SPACE 


B9FCC7 


= 


$EC 


CHANNEL 7 


NO 


SPACE 


B9FCC8 


= 


$ED 


CHANNEL 8 


NO 


SPACE 


B9FCC9 


= 


$EE 


, CHANNEL 9 


NO 


SPACE 
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B9FC10 


= 


$EF 


CHANNEL 10 


NO SPACE 


B9PPPE 


= 


$F0 


NO 


SPACE 


PAGE EJECT 


B9PPBP 


= 


$F1 


NO 


SPACE 


BOTTOM OF PAGE 


B9PPC6 


= 


$F2 


NO 


SPACE 


CHANNEL 6 


B9PPC5 


= 


$F3 


NO 


SPACE 


CHANNEL 5 


B9PPC4 


= 


$F4 


NO 


SPACE 


CHANNEL 4 


B9PPC3 


= 


$F5 


NO 


SPACE 


CHANNEL 3 


B9PPC2 


= 


$F6 


NO 


SPACE 


CHANNEL 2 


B9PP11 


= 


$F7 


NO 


SPACE 


CHANNEL 11 


B9PPC7 


= 


$F8 


NO 


SPACE 


CHANNEL 7 


B9PPC8 


= 


$F9 


NO 


SPACE 


CHANNEL 8 


B9PPC9 


= 


$FA 


NO 


SPACE 


CHANNEL 9 


B9PP10 


= 


$FB 


NO 


SPACE 


CHANNEL 10 


B9FCR1 


= 


$FC 


RESERVED 




B9rCR2 


= 


$FD 


RESERVED 




B9FCR3 


= 


SFE 


RESERVED 





DATA BLOCK FORMAT 



DN 


= 


8 


; DESTINATION NODE 


SN 


= 


9 


; SOURCE NODE 


CN 


= 


10 


; CONNECTION NUMBER 


BTPT 


= 


11 


; BLOCK TYPE/BSN/PRIORITY 


PI 


= 


12 


; PARAMETER 


1 


P2 


= 


13 


; PARAMETER 


2 


P3 


= 


14 


; PARAMETER 


3 


P4 


= 


15 


; PARAMETER 


4 


P5 


= 


16 


; PARAMETER 


5 


P6 


= 


17 


PARAMETER 


6 


P7 


= 


18 


; P«IAMETER 


7 


P8 


= 


19 


PARAMETER 


8 


P9 


= 


20 


PARAMETER 


9 


PIO 


= 


21 


PARAMETER 


10 


Pll 


= 


22 


PARAMETER 


11 


P12 


= 


23 


PARAMETER 


12 


P13 


= 


24 


PARAMETER 


13 


P14 


= 


25 


PARAMETER 


14 


P15 


= 


26 


PARAMETER 


15 


P16 


= 


27 


PARAMETER 


16 


P18 


= 


29 


PARAMETER 


18 


P20 


= 


31 


PARAMETER 


20 


P21 


= 


32 


PARAMETER 


21 


P22 


= 


33 


PARAMETER 


22 


P24 


= 


35 


PARAMETER 


24 


KBYTE 


= 


DN: 


FCD FOR 


FIRST BYTE OF 



* * 

* BLOCK PROTOCOL MESSAGE PARAMETERS * 

* * 



BLOCK 


= DN; 


DBC 


= PI; 


DATA 


= PI; 



FCD OF 1ST BYTE OF BLOCK HEADER 
DATA BLOCK CLARIFIER 

FCD OF 1ST BYTE OF DATA 

* * 

* SM PARAMETER DEFNSE * 

* * 



PFC 
SFC 



= Pi; 
= P2; 



PRIMARY FUNCTION CODE 
SECONDARY FUNCTION CODE 
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FIELD LENGTHS: 

BOIBIT 

B02BITS 

B03BITS 

B04BITS 

B05BITS 

B06BITS 

B07BITS 

B08BITS 

B09BITS 

BOIOBITS 

BO 11 BITS 

B012BITS 

B013BITS 

B014BITS 

B015BITS 

BIT ELEMENTS: 

ELEMENTS 



= 0..1; 
= 0..3; 
= 0..7; 
= 0..15; 
= 0..31; 
= 0..63; 
= 0..127; 
= 0..255; 
= 0..511; 
= 0..1023; 
= O..2047; 
= 0..4095; 
= 0..8191; 
= 0.. 16383; 
= 0. .32767; 



(BIT0,BIT1,BIT2,BIT3,BIT4,BIT5,BIT6,BIT7, 
BIT8,BIT9,BIT10,BIT11,BIT12,BIT13,BIT14,BIT15); 



GENERAL MASK WORD: 

SETWORD = SET OF ELEMENTS; 
POINTERS: 



BOBUFPTR 
BZLCBP 



BOBUFFER; 
BZLCB; 



BUFFER POINTER 
LCB POINTER 



******************************************** 

* 
* 
* 



TERMINAL TYPE (TT)/DEVICE TYPE (DT) 



************************************************************************************** 



NODEVTYPE 


= 0. 


• 7; 


DEVICE 


CODE 


NOTCLASS 


= 0. 


.19; 


TERMINAL CLASS 


NPDT 


= PACKED RECORD 


DEVICE 


TYPE (DT) 




CASE X: INTEGER OF 






1: 


(NPSPRl : 


B08BITS; 


SPARE BYTE 






NPDEV : 


NODEVTYPE; 


DEVICE TYPE 






NPTCLASS : 


NOTCLASS ) ; 


TERMINAL CLASS 




2: 


(NPSPR2, 




SPARE BYTE 






NPCHAR : 


CHAR); 


CHARACTER OVERLAY 




3: 


(NPINT : 


INTEGER); 


INTEGER OVERLAY 




END; 






NOTIPTYPE 


= 0. 


.9; 


TIP TYPE 


NOSUBTIP 


= 0. 


• 7; 


TIP SUB TYPE 


NPTT 


= PACKED RECORD 








CASE X: INTEGER OF 






1: 


(NPSPR3 : 


B08BITS; 


SPARE BYTE 






NPAUTO : 


BOOLEAN; 


AUTO RECOGNITION 






NPTIPTYPE: 


NOTIPTYPE; 


TIP TYPE FIELD 






NPSUBTIP : 


NOSUBTIP); 


TIP SUB TYPE FIELD 




2: 


(NPSPR4, 




SPARE BYTE 






NPCHR : 


CHAR); 


CHARACTER OVERLAY 




3: 


(NPSPR5 : 


B08BITS; 


SPARE BYTE 






NPLS : 


B04BITS ; 


LINE SPEED 






NPCD : 


B04BITS); 


CODE SET 




END; 
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* 



BLOCK TYPE BYTE 



**********************************r******jir***********************************^^ 



BLKTYPE 



PACKED RECORD 




CASE DMY : INTEGER OF 




1: ( 




BTSPRl : B08BITS; 




BTPRID : BOOLEAN; 


PRIORITY DESIGNATOR 


BTBSN : B03BITS; 


BLOCK SERIAL NUMBER 


BTYPE : B04BITS; 


BLOCK TYPE 


2: ( 




BTSPR2, 




BTCHR : CHAR); 


CHARACTER OVERLAY 


END; 





BOLINO = PACKED RECORD 

CASE BOLINTAG : INTEGER OF 

1: (BOLINO: INTEGER); FULL WORD 

2: (BDPORT , PORT NUMBER 

BDSUBPORT:B08BITS); SUB PC»T NUMBER 
END; 



DATA BLOCK CLARIFIER (DBG) 






DBDBC 



= PACKED RECORD CASE DBTAG : INTEGER OF 


1: (DBDMl : CHAR; 


DUMMY 


DBCHAR : CHAR); 


CHARACTER OVERLAY 


2: (DBDLFILL: B08BITS; 


DOWNLINE DBC 


DBDLS 1 , 


SPARE 


DBDLS2, 


SPARE 


DBDLS 3, 


SPARE 


DBDLS4, 


SPARE 


DBDLFE, 


FORMAT EFFECTORS 


DBDLXPT , 


TRANSPARENT 


DBDLS5 , 


SPARE 


DBDLAUTO : BOOLEAN); 


AUTO INPUT 


3: (DBULFILL: B08BITS; 


UPLINE DBC 


DBOLSl, 


SPARE 


DBULS2, 


SPARE 


DBULS3 , 


SPARE 


DBULS4, 


SPARE 


DBULS5 , 


SPARE 


DBULXPT, 


TRANSPARENT 


DBULCAN, 


CANCEL 


DBULPERR: BOOLEAN); 


PARITY ERR 


4: (DBSPl : BOIOBITS; 


SPARE 


DBCCF : B02BITS; 


CODE CONVERSION FIELD 


DBBSF : BOOLEAN; 


BACKSPACE PRESENT FLAG 


DBDBT : B03BITS; 


DATA CLARIFIER 


5: (PDPMl : B08BITS; 


DUMMY 


PDPRUB: BOOLEAN; 


PRUB BLOCK 


PDBANB; BOOLEAN; 


BANNER BLOCK 


PDSPl : B04BITS; 


NOT USED 


PDEOI : BOOLEAN; 


MESSAGE CONTAINS EOI 


PDXPAR: BOOLEAN); 


TRANSPARENT DATA 


6: (DBFl : B08BITS; 


FILL 


DBPRUB , 


PRUB BLOCK 


DBBAHNER, 


BANNER BLOCK 


DBSP2, 


NOT USED 


DBSP3, 


NOT USED 


DBSP4, 


NOT USED 


DBSP5, 


NOT USED 


DBEOI , 


EOI(I) OR EOR(O) BLOCK 


DBCXPT: BOOLEAN); 


TRANSPARENT DATA 


END; 
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INPUT REGULATION OPTIONS FOR PTREGL: 

REGLTYPES = (RELOGUOC, 
RELOCAL, 
REABL, 
REACPINP); 



LOGICAL LINK REGULATION 
LOCAL BUFFER LEVELS 
ALLOWABLE BLOCK LIMIT 
ACCEPT INPUT 



REGLSET 



SET OF REGLTYPES; 



Figure 5-14. System Types Used by the TIP (3 of 3) 



DATA BUFFER SIZE: 

BEDBSIZE ; BECTPTR; 

BUFFER SIZE- INDEX PARAMETERS 

BOSS, 
BOS 16, 
B0S32, 
BOS 64, 



DATA BLOCK SIZE 



EIGHT WORDS 
SIXTEEN WORDS 
THIRTY-TWO WORDS 
SIXTY-FOUR WORDS 



**************************** 

* 

* 

* 



ONE SECOND CLOCK * 

* 

iijtjti********************************************************************************* 
CASECNTR : INTEGER; 

TEXT PROCESSING BUFFER SIZE: 



BETPSIZE : BECTPTR; 
TPBUFLENGTH : INTEGER; 



TEXT PROCESSING BUFFER 
LENGTH 



BUFFER LENGTHS ARRAY: 

BUFLENGTH : ARRAY (BOBUFSIZES) OF INTEGER; 
BUFFER CHARACTER LIMITS: 

BUFLCD : ARRAY (BOBUFSIZES) OF INTEGER; 
BUFFER SIZE MASKS: 

BUFMASKS : ARRAY (BOBUFSIZES) OF SETWORD; 
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Word 


1 

2 



15 13 


12 


8 


7 6 


5 







1 


CNCECODE 


1 


LINE NUMBER 


CLUSTER ADDRESS 


TERMINAL ADDRESS 


DEVICE 

TYPE 


TERMINAL 


CLASS 


SPARE 


ERROR COUNT 




ADDITIONAL USER 


AREA 





Field Name 


Type 


CNCECODE 


INTEGER 


LINE NUMBER 


BO LINO 


CLUSTER ADDRESS 


B08BITS 


TERMINAL ADDRESS 


B08BITS 


DEVICE TYPE 


NODEVTYPE 


TERMINAL CLASS 


NOTCLASS 


SPARE 


B02BITS 


ERRCSl CODE 


B06BITS 



Purpose 

specification of the type of 
error event to be logged in SEE 

line number 

cluster address 

terminal address 

device type 

terminal class 

spare 

number of times this error event 
occurred 



Figure 5-16. System Engineering File Work Area Entry 



60474600 A 



5-29 



BLOCK PROTOCOL 



Block protocol is used to communicate commands and 
information between the NPU and the host. Blocks are 
composed of consecutive bytes. The shortest block 
consists of only a header (four bytes); the longest block 
consists of 2047 bytes, including the four-byte header. 

Block protocol assumes that the logical connection 
between processes in the host and the NPU is error free (a 
supportive, lower level protocol provides delivery assur- 
ances between the processes). However, the logical 
connection can be abnormally broken, either process can 
fail, or the processes can become temporarily congested, 
leading to regulation of information transfer. 

Failure of a process is usually reported by means of a 
service message. Temporary bottlenecks at a destination 
process are usually a result of inability to deliver data to 
an associated terminal or to the host. Block handling 
provides a standard method for informing the transmitting 
process of a temporary problem so that any subseguent 
data transfers on that connection can be held in abeyance 
until the problem is corrected. 

The paths between the two processes are fully sym- 
metrical as shown in figure 6-1. Blocks belong to one of 
three categories: 



Forward supervision (FS) functions are performed 
by INIT and RST blocks. 

Reverse supervision (RS) functions are performed 
by BACK, BRK, STRT, and STP blocks. 

Forward data (FD) functions are performed by 
BLK, MSG, and CMD blocks. 



BLOCK FORMAT 

The first two bytes of any block are reserved for a link 
header (which is used when sending/receiving data from a 
remote NPU). The next four bytes of any block constitute 
the block header. Format of the block header is as shown 
in figure 6-2. 

The current release consists of nine principal block types 
plus an additional assurance control block type used only 
for NPU to NPU transmissions. Characteristics of each 
type are summarized in table 6-1. 

The first three bytes of the block header provide a 
standard network address. Byte 4 contains the block 



NPU 



( XMTR j 



PROCESS 




HOST 



FSi AND FD^ 



RSi 



FS2 AND FD2 



RS2 




PROCESS 



7^ 

I XMTR I 



FS - FORWARD SUPERVISION (CONTROL/STATUS REQUESTS) 
FD - FORWARD DATA (INFORMATION/COMMANDS) 
RS - ACKNOWLEDGMENT AND, ERROR INFORMATION 



Figure 6-1. Sample Block Paths Between NPU and Host 
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Byte 
Bits 



link 
header 



DN 



SN 



CN 



BSN 



DN - Destination node 

SN - Source node 

CK - Connection number 

P - Block priority for trunk usage 

1 = high 
= low 

BSN - Block sequence number (range 0-7) 

BT - Block type (defined in table 6-1) 



3 



BT 



Figure 6-2. Block Header Format 



Remainder 
of block 



TABLE 6-1. BLOCK TYPES 



Mnemonic 


Name 


Block 
Type 


Traffic 
Type 


General Function 


BLK 


Block 


1 


FD 


Any data block which is not the 
EOM block of a multiblock 
message 


MSG 


Message 


2 


PD 


Data block which is the EOM 
block of a multiblock message 
or the only block of a message 


BACK 


Block Acknowledgment 


3 


RS 


Block acknowledgment for block 
transmitted in opposite 
direction 


CMD 


Command 


4 


FD 


Command 


BRK 


Break 


5 


RS 


Indicates a discontinuity in 
the data stream traveling in 
the opposite direction 


STP 


Stop 


6 


RS 


Forward data stream is 
undeliverable and should be 
stopped 


STRT 


Start 


7 


RS 


Forward data stream can be 
started 


RST 


Reset 


8 


PS 


Transmitter has cleared logical 
connection after receiving a 
BRK or STRT 


INIT 


Initiate 


9 


PS 


Initiate a logical connection 






10 
14 




Reserved 
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priority (P), block sequence number (BSN), and block type 
(BT). The content of the remainder of the block, if any, 
varies with the block type. 

The priority of the block is only significant when the block 
is required to traverse a network trunk. Priority provides 
for preferential treatment for high-priority blocks when 
trunk queueinq occurs. (Trunk queueing is a part of pri- 
ority assignment.) All blocks (regardless of type) contain- 
ing the same address must be assigned the same priority. 

The BSN supplied in a downline block of type MSG, BLK, 
or CMD must be returned in the BSN field of the upline 
BACK which acknowledges that block. When a BRK or 
STP is sent, the BSN field must contain the BSN which 
was contained in the last BACK sent for this connection. 
The BSN is always zero on other upline and downline 
blocks. 

ADDRESS 

The address contains the node IDs for the source and 
destination of the block plus a connection number. 



NODE 

Each NPU has a unique node ID; each interface between a 
host and an NPU has a unique node ID; the host has two 
unique node IDs. Node ID = is reserved for the Network 
Supervisor (NS) in the host. One nonzero node (usually 
node 1) is reserved for the Communications Supervisor 
(CS). The remaining node IDs (between 2 and 255) are 
build tinne parameters. For example, in a single-host, 
single-NPU system, the host interface (coupler of the 
local NPU) might be node ID two, and the terminal node 
(interface to the terminals) might be node ID three; this 
pair of nodes forms a logical link. Thus, traffic going 
upline (from a terminal to the host) has a destination node 
ID of two and a source node ID of three. Traffic going 
downline from NS to the NPU has a destination node ID of 
two and a source node ID of zero. 



CONNECTION NUMBER 

A logical connection is the association between a terminal 
device on an NPU and an application process in the host, 
by which traffic is communicated between the terminal 
(or a device at that terminal) and the applicable process. 
The connection number is one byte long, and has a range 
of values between 1 and 255. Every block traveling down- 
line to a terminal device or upline from a terminal device 
bears the connection number. Unique connection numbers 
are assigned to all terminal devices on a given logical link. 



SERVICE CHANNEL 



BLOCK TYPES 

The block types are described in detail below. 



BLK - BLOCK OF A MESSAGE 

A BLK block is a data block containing a portion, but not 
the last segment, of a data message. All data blocks 
contain from 1 to 2043 bytes of data immediately follow- 
ing the four-byte header. The content of the data field is 
determined arbitrarily by the communicating processes; 
that is, the TIP and the host application. 



MSG - MESSAGE OR LAST BLOCK OF A MESSAGE 

A message is a self-contained unit of data communi- 
cations and is transmitted as data stream. An end-of- 
message indicator always terminates the message's data 
stream. 

If a message is 2043 bytes or less in length, it can be 
transmitted within a single MSG block. If a message is 
longer than 2043 bytes or if, as is usual, the message is 
segmented by the terminal or by the TIP, all segments but 
the last are transmitted within BLK blocks. The last 
segment is transmitted within a MSG block. 

BACK - BLOCK ACKNOWLEDGMENT 

A BACK block is the acknowledgment of a received 
block. It is returned to the transmitter by the receiver as 
BLK, MSG, and CMD blocks are processed to allow the 
transmitter to adjust the rate of issuing data to the rate 
of delivery to the receiver. The transmitter should not 
issue unacknowledged blocks in excess of a network block 
limit (NBL) for each connection. The BACK block that 
acknowledges a previously transmitted block allows the 
transmitter to maintain an outstanding block count to 
ensure that the NBL is not exceeded. NBL is established 
by the connection as a part of the configuration process. 
Note that no data bytes are associated with a BACK block. 



CMD - COMMAND BLOCK 

A CMD block carries a network command. It allows 
connected processes to communicate outside of the data 
stream but synchronous with that stream. The command 
is received by the destination process in the same ordering 
sequence to the data stream, or other commands, as 
existed at the source. If CN is 0, the command is a 
service message. The data bytes of the message are 
highly structured. Rather than using BACK blocks as 
acknowledgment, service messages use other service mes- 
sages as acknowledgments. See appendix C. 



A block having a connection number of zero is called a 
service message, and the logical connection over which it 
is communicated is called the service channel. Unlike 
logical connections that can be dynamically created and 
released, the service channel always exists. Service 
messages include commands, requests for status, error 
information, statistics information, or replies to one of 
these three message categories. Commands traveling via 
the service channel establish logical connections and com- 
municate control, status, and error data. The complete 
summary of service messages is found in appendix C of 
the CCP System Programmer's Reference Manual. 



BRK - BREAK IN MESSAGE STREAM 

The BRK block indicates a discontinuity (break) in the 
data stream and travels in the opposite direction. The 
receiving process responds with an RST to specify the 
point in the data stream where the action caused by the 
BRK block occurred. The sender of the BRK block 
discards all blocks received before the RST block. A 
further BRK or STP block must not be sent before the 
RST block is received. 
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A single data byte, the reason code (RC), fallows the BRK 
block header and specifies the reason for breaking the 
transmission. The RC byte is defined as follows: 

1 = User Break 1 received (typically means queue 

abort occurred) 

2 = User Break 2 received (typically means job abort 

occurred) 

3 = Output device not ready 

4 = Illegal or invalidly formatted block received from 

host 

The receiver sends the BRK block v/hen that device is 
unable to determine when data can again be delivered. 
The sender must use a higher level protocol than the break 
condition to determine recovery. 



STP - STOP MESSAGE TRAFFIC 

The STP (Stop) block indicates that no further blocks 
should be sent until a STRT block is received. 

The STP block is used when a process is unable to deliver 
data to the final destination but is able to determine when 
data delivery can resume. The STP block is used to 
release data buffered in the network; STP blocks are not 
required for temporary delays. A reason code follows 
the header. This code is passed to the connected process. 
The sender of the STP block discards all sequenced blocks 
received. The RC byte is interpreted as follows: 

1 = Terminal busy 

2 = Terminal failure 

3 = Batch interrupted by interactive input or output 



STRT block. The receiving process responds with a RST. 
No data bytes are associated with this block. 

RST - RESET BLOCK 

The RST (reset) block is sent in response to either a BRK 
or STRT block. It serves to delimit the data stream and 
indicate the point at which the BRK or STRT block 
occurred. From the time the BRK or STRT block was sent 
until the receipt of the RST block, all unacknowledged 
blocks and all new blocks are discarded. No data bytes 
are associated with this block. 



INIT - INITIALIZE TRAFFIC 

The INIT (initiate) block delimits the new data boundaries 
when a connection is first made. Newly established 
connections discard blocks from the logical connection 
until the INIT protocol is completed. The second end of 
the connection to be set up immediately sends an INIT 
block. Upon receipt of the INIT block, the first end to be 
set up responds with an INIT block and starts accepting 
blocks over the logical connection. Upon receipt of the 
responding INIT block, the second end of the connection to 
be set up also starts to accept blocks over the logical 
connection. No data bytes are associated with this block. 



BAD BLOCKS DETECTED BY NPU 

When NPU software detects a bad block, the NPU discards 
the block. If the block is bad due to a bad block type or to 
a bad sequence number, a BRK block is sent to the host. 
If the block is a BLK, CMD, or MSG, no BACK block is 
sent to the host. For any other block type, no action 
solicited by the block is taken and the block is not ac- 
knowledged. 



STRT - START MESSAGE TRAFFIC 

The STRT (Start) block is used after a STP block to allow 
resumption of data flow to the destination sending the 
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BLOCK PROTOCOL INTERFACE PACKAGE (BIP) 



The Block Protocol Interface Package (BIP) controls the 
transportation of data and control blocks between the TIP 
and the application program. BIP provides a set of 
modules which the TIP uses to receive data, to send data, 
and to regulate the flow of data. Two independent 
processes for data and commands are provided: one for 
upline and the other for downline. 



DOWNLINE DATA AND COMMANDS 

After line and terminal configuration has been completed, 
the host software and the BIP initialize the connection for 
both upline and downline data. This initialization discards 
any residual messages that might have been left in the 
network from a previous use of the connection (CN). This 
initialization is invisible to the TIP. The host application 
programs are required to originate a downline message to 
begin data exchange. The TIP uses this first downline 
message to indicate that the connection has been 
initialized, and to begin I/O tasks. 

Whenever an output message arrives from the host, BIP 
queues the message to the appropriate TCB. Whenever 
BIP places a message in an empty TCB queue, BIP also 
generates a worklist entry for the TIP associated with 
that TCB. (Note that BIP does not generate a worklist 
entry to the TIP if there are already messages in the TCB 
queue.) This worklist can be used to initiate output. 
After the output operation is completed, the TIP must 
check to find if there is more output queued for delivery. 
Format of the output queued worklist entry to the TIP is 
shown below: 



Output Q 
Word 


jeued WLE: 
15 14 


8 7 










1 AOQUEOUT 


1 


line number 


2 


TCB address 



Procedure name: PBPROPOl 

Input parameter: (BITCB) = address of TCB 

Return parameter: (BIBUFF) = address of first 
buffer in chain (or nil if 
there is nothing in queue) 

Calling sequence: PBPROPOl 

Example of call; 

BITCB ; = (tcbpointer); Address of TCB to be 

checked 
PBPROPOl; Get next output message 

IF BIBUFF = NIL If no messages,... 

THEN 



ELSE 



ELSE, IF OUTPUT EXISTS.. 



The message which was removed from the output queus 
must be acknowledged before calling PBPROPOl again. 
The message can be acknowledged by calling the post- 
output point of interface (PBPOPOI), PTBACK, PTSTOP, 
or PTBREAK. Message and terminal conditions determine 
which routine is called. PBPOPOI is used to acknowledge 
data messages (BLK or MSG blocks). Commands are 
acknowledged by calling PTBACK. PTBREAK (a negative 
acknowledgment) is called if the message can be neither 
delivered nor actioned. Such conditions could be caused 
either by syntax errors in the message or a device- 
not-ready condition at the terminal. The BRK block is 
used for device-not-ready only if the TIP cannot deter- 
mine when the device-ready condition occurs. If the TIP 
can resolve the not ready condition, PTSTOP is called 
instead. The STP block does not acknowledge a message 
if the message was unqueued. 



PREOUTPUT POINT OF INTERFACE 

The TIP checks for pending output by calling the 
preoutput point of interface procedure, PBPROPOl. If 
output is available, PBPROPOl returns the address of the 
chain of message buffers to the TIP. Otherwise, a nil 
pointer is passed to the TIP. 

The principal characteristics of PBPROPOl are as follows: 



POST OUTPUT POINT OF INTERFACE 

After successfully transmitting data to a terminal, the 
TIP calls the post output point of interface program, 
PBPOPOI. This program performs the following functions: 

• It acknowledges to the host application program 
that the block was successfully transmitted 

• It accumulates line and terminal statistics 

• It releases the data buffers 
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CCP must acknowledge all the blocks that an application 
program sends and it must acknowledge them only once. 
It is possihle for a network block to be fragmented into 
two or more blocks. Each of these internally generated 
blocks is identified by a BFINTBLK flag which is set to 
TRUE in the first buffer of the block. The TIP must pass 
this flag to the transmission block so PBPOPOI can 
recognize that it is not to be acknowledged. When 
PBPOPOI processes one of these internally generated 
blocks, it accumulates statistics for the block. However, 
since only one fragment of the block has BFINTBLK set to 
FALSE, PBPOPOI acknowledges that transmission block 
only. 

Note that PBPOPOI must not be called more than once for 
any network block without the BFINTBLK flag set, since 
this would cause multiple acknowledgment of a single 
network block. 

PBPOPOI's principal characteristics are as follows: 

Procedure name: PBPOPOI 

Input parameter: (BITCB) = address of TCB 

Return parameter; (BIBUFF) = address of buffer 
chain 

Calling sequence: PBPOPOI 

Example of call : 

BITCB : = (tcbpointer); TCB address 

BIBUFF : = (buff erpointer); Buffer chain address 

PBPOPOI; Acknowledge block 



COMMAND ACKNOWLEDGMENT 

After the TIP processes a command, the TIP acknowledges 
command (CMD) blocks by calling PTBACK. This 
procedure must be called only once for each CMD block. 

PTBACK's principal characteristics are as follows: 

Procedure name: PTBACK 

Input parameter: (BITCB) = address of TCB 

Return parameter: none 

Calling sequence: PTBACK 

Example of call: 

BITCB : = (tcbpointer); TCB address 

PTBACK; Acknowledge the CMD block 

NEGATIVE ACKNOWLEDGMENT OF BLOCKS AND BREAKS 



A negative acknowledgement takes the form of a break 
(BRK) block, which is generated by the PTBREAK 
routine. Negative acknowledgement is sent to the host 
application program whenever the TIP cannot deliver a 
data (MSG or BLK) block, or is unable to execute a CMD 
block. PTBREAK is called when the TIP detects a syntax 
error or a sequence error in either a data or a command 
block. PTBREAK is also called when the data cannot be 
delivered for an indeterminate period, as when the 
receiving terminal is not ready. The host application 
program must provide the logic to restart the output 
operation when the terminal is again able to accept data. 



BRK blocks have a second use: they can carry user data 
upline for special processing. For example, when a user 
break is entered at a terminal, a break block is generated 
for the application program. In this case, BRK block is 
inserted into the data stream to carry upline data; it is 
therefore not synchronous with other upline network 
blocks. Since the BRK block can never be synchronous 
with the normal data stream, it can be received and 
processed ahead of any data or commands that were 
queued for upline transmission prior to the BRK block, but 
which the application has not yet received. 

If (1) delivery assurance is required, and (2) the output 
block was fragmented, and (3) the TIP did acknowledge 
the network block without delivering all of the 
fragmented blocks, then the TIP must hold the fragmented 
blocks either until they can be delivered or until the 
connection is broken. However, if the failure to deliver 
all of the fragments was caused by a user break received 
from the terminal, all queued blocks are discarded; there 
is no delivery assurance for this condition. 

NOTE 

The BACK block is used only for data flow 
control. Delivery assurance requires some 
other mechanism, such as passing CMD 
blocks between nodes. None of the 
standard CCP TIPs use delivery assurance. 

PTBREAK's principal characteristics are as follows: 



Procedure name: 



Input parameters : 



PTBREAK 

(BITCB) = address of TCB 

(reason code) = integer 

variable: 

Type of break condition: 

B9F(SIMAT = syntax or sequence 

error 

B90DEVN0TRDY = Output device 

not ready 

B9USR1 = user break 1 

B9USR2 = user break 2 



Return parameter: none 

Calling sequence: PTBREAK (reason code); 

Example of call: 

BITCB : = (tcbpointer); TCB address 
PTBBREK(B9F0RMAT); Syntax error in message 

STOP OUTPUT 

The TIP can stop the downline data and command flow at 
any time by calling PTSTOP to generate a STP block. A 
stop block causes the host application to suspend output 
until a start condition is sent upline. The STP block acts 
as a negative acknowledgment if a network block was 
unqueued but not acknowledged. The host application 
repeats all unacknowledged messages when the downline 
data flow is restarted. The TIP must not send a BRK 
block while a STP block is outstanding (that is, no STRT 
block has been generated to restart output from the host 
application program). 

PTSTOP's principal characteristics are as follows: 
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Procedure name: PTSTOP 

Input parameters: (BITCB) = address of TCB 

(reason code) = reason code 
for the stop 
Type of stop condition: 
B9TBUSY = terminal busy 
B9TFAILURE = terminal failed 

Return parameter none 

Calling sequence: PTSTOP (reason code); 

Example of call: 

BITCB : = (tcbpointer); TCB address 
PTSTOP (B9BUSY); Stop downline message 

flow 

START OUTPUT 

To restart an output stream that was previously stopped 
by the call to PTSTOP, the TIP issues a call to PTSTART. 
That routine sends a STRT block upline if, and only if, the 
last block sent upline was a STP block. 

PTST ART'S principal characteristics are: 

Procedure name: PTSTART 

Input parameters: (BITCB) = address of TCB 

(reason code) = constant of 
type INTEGER, which is always 
set to a zero value 

Return parameter: none 

Calling sequence: PTSTART (reason code); reason 
code is always zero 

Example of call: 

BEGIN 

BITCB : = (tcbpointer); TCB address 
PTSTART(O); start downline 

message flow 

END; 



UPLINE DATA AND COMMANDS 



Before starting any input processing, or releasing any 
upline data into the network, the TIP must make an input 
data regulation check to find if input is allowed. The TIP 
calls PTREGL to determine the current input conditions. 
If input is allowed, the TIP requests input from the 
terminal or allows already gathered messages to be 
released to the network. The TIP calls the post input 
point of interface, PBPIPOI, to transform the data into 
network MSG or BLK blocks, and to pass the blocks upline 
to the network. 

UPLINE COMMANDS 

Commands can be sent upline either as a response to a 
downline command, or as a result of upline data. In either 
case, the TIP calls the Internal Input Point of Interface, 
PBIIPOI, to send a command. 

POST INPUT POINT OF INTERFACE 

Whenever the TIP has data that is ready to be sent to the 
host application program, the TIP calls the post input 
point of interface routine, PBPIPOI. This POI performs 
three tasks: it creates a network block, it routes the block 
to the host, and it gathers line and terminal statistics for 
the data. 

PBPIPOI's principal characteristics are as follows; 



Procedure name: 



Input parameters: 



PBPIPOI 

(BIBUFF) = address of data 
buffer chain 
(BITCB) = address of TCB 
(BIBT) = block type: 

HTMSG = message 

HTBLK = block 



Return parameter: none 

Calling sequence: PBPIPOI 

Example of call: 

BIBUFF : = (buff erpointer) ; Address of input data 
BITCB : = (tcbpointer); TCB address 
BIBT := HTMSG; Message block 

PBPIPOI; Send message to 

application program 



UPLINE DATA 

After terminal configuration is completed, it is possible 
for the TIP to initiate and to process upline data. 
However, the network cannot accept upline data until the 
connection to the host application program is initialized. 
Synchronous and asynchronous protocols should start 
processing data in different ways: 

■ Synchronous TIPs should wait for the first 
downline data to indicate that the connection has 
been completed. 

• Uncontrolled protocols which are used with 
asynchronous terminals can lose the first few data 
characters if the TIP waits for an indication that 
the connection has been completed. For such 
protocols, the first output from the application 
program to the terminal is a prompt, indicating a 
successful connection. 



Prior to calling PBPIPOI, the TIP should call PTREGL to 
assure that the connection has been initialized and can 
accept data. Otherwise, data could be lost. 

The first character displacement (FCD) of the first data 
buffer must point to the first data character and not to 
the first header byte. The first data character is defined 
to be the data block clarifier (DBC). If the DBC is in the 
proper relative location in the buffer, the system adds the 
network header to the first buffer. If the DBC is in any 
other byte, the system allocates a new buffer for the 
network header and chains the data buffers to the new 
header. This inefficient use of data buffers should be 
avoided. The TIP should normally place the DBC in the 
byte indexed by the global constant DATA. (The global 
variable DBC is equated to DATA to allow more 
descriptive code.) Following the DBC, the first 
transformed data byte from the terminal in placed at 
location (DATA + 1). The TIP normally prepares the FCD 
and DBC as shown: 
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VAR 

(dbc) : DBDBC Data block clarifier 

WITH BIBUFF + DO With the data buffer 

BEGIN To be sent 

BFFCD : = DATA; Indicate the location of 

the DBC 
BFDATAC mBc] : = 

(dbc).DBCHAR; Set the message DBC 
END; 

INTERNAL INPUT POINT OF INTERFACE 

To send a command to the host, the TIP constructs the 
command in a data buffer and calls the internal input 
point of interface, PBIIPOI, to format the command into a 
network recognized CMD blocl<, and to send the block 
upline. The first data byte of the command should begin 
at an index specified by the global constant DATA (this 
avoids inefficient use of data buffers). 

PBIIPOrS principal characteristics are as follows: 

Procedure name: PBIIPOI 

Input parameters: (BIBUFF) = address of command 
(BlTCB) = address of TCB 
(BIBT) = HTCMD - Network 
command block type 

Return parameter: none 



Calling sequence: PBIIPOI 

Example of call: 

BIBUFF := (bufferpointer); Address of command 

data 
BlTCB : = (tcbpointer); TCB address 

BIBT := HTCMD; Command block 

PBIIPOI; Send command to host 

MESSAGE SEQUENCING 

Each downline BLK, MSG, or CMD block is given a 
sequence number by the network software. This sequence 
number is returned to the host in the acknowledgment for 
the block. BIP maintains the sequence numbers, but the 
the TIP must assure that interface procedures are called 
in the proper order. Failure to maintain this order causes 
the host software to report an NPU failure. This will lead 
to reloading the NPU and causes the loss of all current 
messages, as well as a loss of time in reloading the NPU 
and reconfiguring all its lines. 

ERROR PROCESSING 

Illegal parameters passed to the BIP routines will result in 
the eventual failure of the NPU. The BIP does not check 
input parameters to protect the system against failures 
resulting from erroneous TIP calls. 
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SERVICE MODULE INTERFACE 
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The Service Module (SVM) provides the interface for 
supervisory (service) messages between the TIP and the 
host. 

Downline, a service message from the host originates as a 
request to change the status of a line or a terminal. The 
service module forwards the request to the TIP for 
processing or for TIP concurrence. In most cases the TIP 
must reply to the service module request. However, the 
TIP need not reply immediately. Instead, the TIP can save 
the request and continue processing until an appropriate 
time is found to send the reply. Such delays are often 
necessary to complete a protocol cycle so that the 
terminal is left in a known state rather than in some error 
or recovery state. 

Upline, the TIP can generate a service message when the 
TIP detects a change in the status of a line or terminal. 
In this case, the TIP calls the service module to forward 
the change of status to the host in the form of a 
supervisory message. The TIP also gathers statistics for 
the host's engineering file, and calls the service module 
indirectly to deliver this information to the host. Note 
that this information is independent of the application 
programs. Such information is for diagnostic purposes; it 
is independent of online message processing. 

There are three methods of interfacing to the service 
module: 

• Most communication between TIP and service 
module is initiated by worklist entries. 

• The service module makes a direct call to the 
TIP'S TCB initialization routine during terminal 
configuration. 

• The TIP calls other routines which in turn call the 
service module, thereby providing indirect calls to 
the SVM. 

The following tasks use the TIP/SVM interface: 

• Worklist call from SVM to TIP to enable a line. 
The TIP must reply to the SVM with a line enabled 
or a line inoperative worklist. 

• Worklist call from SVM to TIP to disable a line. 
The TIP must reply to the SVM with a line 
disabled worklist. 

• Direct call from SVM to TIP to configure user TIP 
defined fields of the TCB. The TIP must return 
control to the SVM by completing the return jump. 

• Worklist call from SVM to TIP to start terminal 
operation following configuration. There is no 
reply to this service message. 

• Worklist call from SVM to TIP to change a data 
connection from the terminal to another appli- 
cation program. The TIP must reply to the SVM 
with a terminal reconfigured worklist. 



• Worklist call from SVM to TIP to delete a 
terminal. The TIP must reply to the SVM with a 
terminal deleted worklist. 

• Indirect call to SVM via PNSMGEN to report a 
change of terminal status (such as a terminal 
failure or recovery). 

• Indirect call to SVM via PNCEFILE to report 
statistical performance data. 

ENABLE LINE 

A line enable worklist is sent to the TIP when a line is 
being initialized for use and the modem signals are 
correct. The TIP initializes the TIP-defined fields, if 
necessary. The enable line worklist is sent to the TIP for 
both the initial line configuration and for reinitialization. 
Reinitialization can result from a line enable or a 
disconnect line request from the host. 

The TIP must reply to the SVM with either a line enabled 
worklist (workcode = COLINOP), or a line inoperative 
worklist (workcode = COLNINOP), depending on the TIP's 
success in enabling the line. 

The TIP must do additional processing on autorecognition 
lines (the LCB's BZAUTO field = TRUE). The TIP 
communicates with the terminal, and the operator replies 
by pressing certain keys which send information for the 
TIP to interpret. By using autorecognition methods the 
TIP can determine the following: 

Line speed 
SubTIP type 
Code set 

Cluster address(es) 
Terminal address(es) 
Device type(s) 

The TIP places the detected information in specified 
fields of a data buffer. This buffer is passed to the SVM 
along with the worklist entry for the line enabled reply. If 
the TIP failed to generate any autorecognition infor- 
mation, the address of the autorecognition buffer will be 
NIL. SVM passes all autorecognition information to the 
host. 

NOTE 

Implementing new autorecognition para- 
meters requires host program changes. 
New use of existing autorecognition fields 
may also require host program changes. 

If the TIP writer uses a dummy TCB during auto- 
recognition, the TIP itself must both create and maintain 
this TCB. 

The service module assures that only one enable line 
worklist is sent to the TIP for each line. Terminal related 
requests are not sent to the TIP until SVM receives the 
TIP'S reply to the enable line message. However, SVM can 
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send the TIP a disable line worklist to cancel the auto- 
recognition procedures at any time. 

Figure 8-1 shows the worklist entry format for the enable 
line request and for the TIP's worklist replies to this 
request. 



After initializing the fields, the TIP completes the return 
jump to the service module. 



Enable Line WLE 



15 


8 7 





I AOSMEN 


line number 



Line Enabled WLE 



15 8 


7 




COLINOP 1 


line number 


address of autorec buffer 



15 



Line Inoperative WLE 



8 7 



COLNINOP 



line number 



Figure 8-1. Enable Line Worklists and Replies 



DISABLE LINE 

When the host decides to discontinue use of a line, it sends 
a disable or disconnect request to the NPU. The service 
module processes its part of the request and passes a 
disable line worklist to the TIP. The TIP terminates any 
activities on the line and then sends a line disabled 
worklist to the service module. The TIP need not return 
the reply immediately, however. Instead it may delay any 
reply until the terminal is left in a known state. The TIP 
must release all internally maintained buffers for the line, 
including all the buffers held in each TCB on the line. The 
service module releases the TCBs. 

The format of the disable line worklist to the TIP, and the 
format of the TIP's reply worklist to the service module 
are shown in figure 8-2. 

CONFIGURE TERMINAL 

After the line is enabled, the host can request that the 
terminals on that line be configured. The service module 
handles a large part of this configuration process and then 
calls the TIP directly to finish configuring the terminal. 

The TIP must contain a separate subroutine to handle this 
call. The TIP's part of the configuration process normally 
consists of initializing the value of TIP-defined fields in 
the TCB (and in some cases the LCB). 





15 


Disable Line WLE 
8 7 











AOSMDA 


line number ] 




15 


Line Disabled WLE 
8 7 









COUilDA 













Figure 8-2. Disable Line Worklists 



NOTE 

If the TIP returns control to the monitor 
from this subroutine, the NPU will fail. 

The TIP must not begin I/O at this time, as the connection 
is not yet open and data cannot be sent from the terminal 
to the host. 

After both the TIP and the service module have completed 
the terminal configuration, the service module notifies 
the host and sends a TCB-configured worklist to the TIP. 
When the TIP receives this worklist, the TIP writer has a 
choice of coding options: 

■ The TIP can be coded so that the TIP initiates I/O 
with the terminal at this time. However, note 
that it may still be necessary to inhibit input 
because the connection is not yet initialized. The 
TIP discovers whether or not input can be 
accepted by calling PTREGL directly. 

• The TIP can be coded to wait for the first output 
block from the host as the event which initiates 
both input and output for the terminal. This first 
output block is either (1) the request from the 
network for log on information, or (2) the first 
message from a user-written application pro- 
gram. In either case, the BIP sends a worklist to 
the TIP since this is the first block in the TCB's 
output data queue. 

Note that the TIP does not return a worklist to the service 
module to reply to the TCB-configured worklist. 

The principal characteristics of the configure TCB process 
are as follows: 

Procedure name: Chosen by the TIP writer 

Input paramters: (BITCB) = address of TCB 

Output parameters: None 
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Processes: 



Required system 
table changes: 



Initialize values of 
TIP-defined TCB fields, if 
necessary 



Address of TCB configuration 
routine must be initialized 
in the TIP type table. 



Figure 8-3 shows the format of the TCB configured 
worklist sent from the service module to the TIP. 



Word 
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2 
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Figure 8-3. TCB Configured Worklist 
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AOSMRCTCB 




line number 


TCB address 


Terminal Reconfigured WLE 




15 8 7 




[ CORCTCB 




TCB address 







Figure 8-4. Reconfigure TCB Worklists 



RECONFIGURE TERMINAL 

A reconfiguration request from the service module 
indicates that the host is switching the data connection 
from one application program to another. The TIP must 
return the TCB to the same initialized state as if it were 
newly configured. When the TIP has finished its part of 
the reconfiguration process, the TIP sends a TCB recon- 
figured worklist to the service module. 

The TIP reconfiguration process consists of the following 
actions: 

• All internally held data buffers are released. 

• All TIP-defined fields in the TCB are initialized. 

■ The TIP initiates I/O on the connection in the 
same way it initialized I/O for a configuration 
process. 

It is especially important that the terminal be left in a 
known state since this request is a normal part of the 
switching procedure between application programs. All 
residual effects of the old application program should be 
eliminated and all current protocol cycles should be 
allowed to go to completion. The TIP should delay the 
reply to the reconfiguration request until all the above 
actions are completed. However, the TIP must reply to 
the request even if the line fails and the service module is 
sent a line-inoperative status worklist. 

The service module will not send a second reconfiguration 
request for the same terminal until the TIP replies to the 
first reconfiguration request. Furthermore, if the TIP has 
not replied to a reconfiguration request, the service 
module will not send a line disable request for that 
terminal's line. Note, however, that there is no limitation 
on sending configure TCB, reconfigure TCB, or disable 
line requests for any other terminal controlled by the TIP. 

If a terminal has failed, the TIP must retain this infor- 
mation. A request to change a connection does not 
change the error status of the terminal. 

Figure 8-4 shows the worklist formats for the recon- 
figuration requests. 



DELETE TERMINAL 

When the host requests that a terminal or a terminal 
device be deleted, the service module sends a delete 
terminal worklist to the TIP. To process this request the 
TIP must accomplish the following: 

• Release all internally held buffers 

■ Save any data in the TCB which the TIP has 
reason to retain 

• Unqueue the TCB from the chain of active TCBs 
for the line 

• Reply that the above actions have been completed 
by sending a terminal deleted worklist to the 
service module. The service module will not send 
a delete line request for this terminal's line if the 
TIP has not replied to a previous delete terminal 
request. 

The TCB unqueuing process proceeds as follows: 

• The TIP finds the pointer to the first TCB linked 
to the line. This pointer is held in the LCB field, 
BZTCBPTR. 

• If this pointer is for the TCB to be deleted, the 
TIP moves the pointer to the following TCB into 
BZTCBPTR. This pointer is contained in the TCB 
field, BSCHAIN. 

■ If this pointer is not for the TCB to be deleted, 
the TCB chain in each TCB's BSCHAIN field is 
searched until the TCB preceding the TCB to be 
deleted is found. That TCB points to the TCB to 
be deleted. That TCB's BSCHAIN field is loaded 
with the BSCHAIN field from the TCB to be 
deleted. 

Figure 8-5 shows the delete terminal worklist formats. 



TERMINAL STATUS CHANGES 

If a TIP detects changes in a a terminal's status, the TIP 
passes the information indirectly to the service module by 
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Word 
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Delete Terminal WLE 

8 7 






AOSMDLTCB 1 




line number 


TCB address 


15 


Terminal Deleted WLE 

8 7 






CODLTCB 




TCB address 









Figure 8-5. Delete Terminal Worklists 

means of a direct call to PNSMGEN. The service module 
subsequently sends the appropriate service message to the 
host. 

The procedures for reporting status changes are as foUow^s: 

■ The TIP detects an irrecoverable error such as a 
protocol failure. 

• The terminal must be configured at the time. 

• The TIP collects the status change information 
and calls the SVM indirectly. 

• When the error condition is resolved and the 
terminal can again be used, the TIP again reports 
the change of status via PNSMGEN. 

• The host supervision does not have to act on a 
failing terminal status change. Application pro- 
grams can be written which will not relinquish a 
connection even though the terminal has failed. 

• The TIP must also initiate sending a STP block to 
the application by means of a direct call to 
PTSTOP. This will stop transfers on the con- 
nection. The application program can be written 
in either of two ways: (1) The application can 
relinquish the connection to the network, or (2) 
the application can retain the connection and wait 
for a STRT block to be sent, indicating that the 
terminal has recovered. 

If the application relinquishes the connection, the host 
sipervisor can send a message downline to reconfigure the 
terminal without initializing the data path (that is, the old 
connection is ended, but no new connection is defined). In 
this case, protocol blocks are inhibited from using the 
path, since there is no receiving application program. The 
host supervisor then waits for an operational status 
service message before any new connection is estab- 
lished. (The TIP notifies PNSMGEN that the terminal's 
status has changed to operational; the service module 
sends the message upline.) The host supervisor establishes 
the new connection by a second reconfigure message for 
the same terminal. 

If the TIP cannot detect that the failed terminal has 
recovered, both the connection and the terminal are 



unusable until the network operator intervenes. The TIP 
receives notification of the operator's intervention in the 
form of a delete terminal request or a disable line request. 

The TIP must retain the operational or nonoperational 
status of the terminal throughout the reconfiguration 
process. The TIP must not reissue a terminal inoperative 
status as a result of the reconfiguration request. Since 
the STP block sent on the original connection is not 
transferred to the new connection, the STRT block must 
be cancelled. 

The principal characteristics of the terminal status 
change process are shown in figure 8-6. 



SYSTEM ENGINEERING FILE ENTRIES 

Entries are made in the system engineering file for 
periodic statistical analysis. Entries help the analyst to 
diagnose patterns of failure and to identify marginal 
components. 

The TIP constructs the entry format in a work area and 
calls PNCEFILE to generate and to send the appropriate 
type of CE ERROR message to the host. The TIP writer 
must define the various fields in the entry. See section 5 
for the recommended field definitions and field types. 
Additional user information can be added to the entry; 
however, new formats may require corresponding changes 
in the engineering file analyzer. In addition, the engi- 
neering file analayzer may need changes if the TIP writer 
adds new error file entry codes. No provision is made for 
the creation of new alarm messages to the network oper- 
ator as a result of newly defined engineering file entries. 

The principal characteristics of the system engineering 
file entry generating process are as follows: 



Procedure name: 
Input parameters: 



Return parameters: 
Calling sequence: 



PNCEFILE 

(length) = length of the 
prototype entry in eight bit 
bytes 

(CNCEOVLY) = prototype entry 
constructed prior to the 
call to PNCEFILE 

None 

Initialize the prototype 
entry in the work area 

Call PNCEFILE, passing the 
entry length as a parameter: 

PNCEFILE (length) 



Figure 8-7 shows an example of calling the service module 
to generate a CE error service message. 

ERROR PROCESSING 

The system may fail in the following cases: 

■ The TIP sends a worklist to SVM which is not in 
reply to a SVM worklist, and is not one of the 
acceptable unsolicted worklists (unsolicited line 
and terminal status requests are acceptable). 
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Line number or TCB address in the worklist to 
SVM is incorrect. In most cases, the illegal value 
causes destructive changes to memory which leads 
to an eventual NPU failure. If SVM detects the 



error, that module executes an immediate system 
halt. It should be apparent that the TIP writer 
must carefully validate his SVM interface. 



Procedure name: 



PNSMGEN 



Input paramters: (GENPFC) = D8STATUS 
(GENSFC) = D9TMLSTAT 
(OP) = TCB address 
(BSINOP) =- Terminal status (operational = TRUE, inop = FALSE) 

Output parameters: None 

Calling sequence: The global variables GEMPFC and GENSFC are INTEGER type. The global constants D8STATUS 
and D9TMLSTAT are provided for use with this call. The global variable must be set up 
immediately preceding the call. 

The global OP is of BOBUFPTR type. 

The boolean variable BSINOP is a flag in the TCB. The TIP sets and clears this flag. 

The TIP cannot call the service module directly. Therefore an indirect call is made to 
PNSMGEN. The array BRTNJUMP, the constant CIPNSMGEN, the fields JENTADDR and JPAGEVAL 
m the array BRTNJOMP and the procedure PBXFER are all system defined. The TIP writer 
should use the code shown in figure 8-6 to make the call. 



Figure 8-6. Terminal Status Change Call to Service Module 



WITH <tcbpointer> +Dd 

WITH CNCE OVLY |<level> 
BEGIN ' 

CNCECODE 
<line number> 
<cluster address> 
<terminal address> 
<device type> 
<terminal class> 
<error count> 
PNCEFILE (<length>); 
END; 

where: 

<tcbpointer> 
<level> 



Dd 



<error file entry code>; r*-entry code 

<lcbpointer> +.BZLINO; 

BSCA; 

BSTA; 

BSDEVTYPE ; 

BSTCLASSi 

<occurrence count>; 



+ 
r*-line number 4. 

r»-cluster address + 
rvterminal address-). 
r»-device type + 

r*-terminal class + 
i*occurrence count + 
r». issue SEF entry 4. 



<error file entry code> = 

<line number> = 

<lcb pointer> = 

<cluster address> = 

<terminal address> = 

<device type> = 

<terminal class> = 

< error count > = 

<occurence count> = 



pointer variable to TCB 

interrupt level constant 

OPS = OPS level (normal) entry to TIP 
MIJX2 = MUX level entry to TIP 

defines entry 

user should select values X'40 to X'4F 

line number and terminal reporting error 

pointer variable to LOB 

entries from TCB defining 
terminal with problem 

count field for this error 
value for count field 



Figure 8-7. Sample Call to SVM to Generate a CE Error Message 
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COMMON TIP SUBROUTINES 



CCP provides a variety of subroutines to perform func- 
tions that are common to several TIPs. These common 
functions are as fallows: 

• To check if input regulation should occur 

• To provide reentrant code entry and exit pro- 
cedures 

• To process IVT commands 

■ To gather error processing statistics 

INPUT REGULATION, PTREGL 

Before a TIP can solicit or allow upline data, the TIP must 
check the upline traffic conditions to find if input should 
be regulated (inhibited). Four types of conditions can 
cause the TIP to regulate input. The TIP has the choice of 
checking for any of these conditions or any combination of 
these conditions: 

■ The data path from the terminal is congested with 
too nnany upline blocks. This condition occurs 
when the number of network blocks sent to the 
host, but not yet acknowledged, exceeds the user 
defined threshold value. 

• The data path from the host to an NPU attached 
to the terminals is congested because of a failed 
intermediate node or a shortage of data buffers in 
an intermediate node. An intermediate node is 
defined to be any NPU that is upline from an NPU 
which has attached terminals. 

• The node attached to the terminals is itself con- 
gested, and has too few assignable data buffers to 
allow further input from the terminals. 

■ The data path from the terminal to the host appli- 
cation program has not been initialized. 

The TIP issues a call to the boolean function, PTREGL, to 
determine if one or more of these regulation causing 
conditions exists. 

The principal characteristics of the regulation checking 
subroutine are as follows: 



Procedure name: 
Input parameters : 



PTREGL 

(tcbpointer) = address of the 
TCB 

(regltype) = variable of tjrpe 
SETWOBD with the following 
values: 

EGLOGUJK = logical link 
regulation 



REABL = network block limit 

REACPINP = connection 
initialized status 

RELOCAL = data buffer 
shortage in this NPD 

Output parameter: input regulation status, type 
BOOLEAN. 

TRUE = input allowed 

FALSE = at least one of the 
requested types of regulation 
condition exists. 

Calling sequence: (regvalue) := PTREGL 
((tcbptr),(regtype)) 

Example of call: 

IF PTREGL(B1TCB, RELOGLNK, REABL, REACPINP, RELOCAL ) 
THEN 

BEGIN ALLOW INPUT FOR THIS 

TERMINAL 



END; 



For controlled protocols, the TIP may discover the status 
of all the possible conditions prior to permitting input. 
For uncontrolled protocols, the terminal's input may be 
accepted by the TIP and then discarded. The terminal 
must be notified that the input was discarded in these 
cases. 

REENTRANT CODE ENTRY AND EXIT 
PROCEDURES 

If the TIP supports more than one line, the TIP must use 
reentrant coding to use the network effectively . It is 
possible that the reentrant code could be written for each 
entry to the TIP so that the TIP would relinquish control 
with a normal exit. Given the modular structure of TIPs, 
it is more likely that the TIP will relinquish control within 
a subroutine while waiting for an external event to occur. 
The occurrence of the event will cause the TIP to reenter 
the subroutine at the point where control was relin- 
quished, and to continue processing. The type of reen- 
trancy cannot be handled by the push down stack logic 
which the PASCAL compiler provides. 

The common subroutine is vin-itten so that the TIP 
executes code to set up to await the external event, and 
then exits to the system by calling one of two exit 
procedures: PTSVILCB or PTSV2LCB. Since each routine 
saves the address of its call in the line control block 
(LCB), only one call may be outstanding for each routine 
at any one time. Only the return address is saved; the TIP 
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TABLE 9-1. CCP INTERRUPT LEVELS 



Hardware 
Line No. 



10 



11 



12 



13 



U 



15 



Software 
Priority 



PI 



P6 



P2 



P3 



P16 



P5 



P7 



P8 



P9 



PIO 



Pll 



P12 



P13 



P14 



P15 



P17 



Interrupt Descriptxon 



INTERNAL 



TELETYPE (CCP CONSOLE) 



MULTIPLEX LOOP ERROR 



MUX-2 LEVEL 



1742-30 LINE PRINTER (CONSOLE OPTION) 



SPARE 



COUPLER 



SPARE 



REAL TIME CLOCK 



1742 LINE PRINTER (CONSOLE OPTION) 



SPARE 



SPARE 



MLIA OUTPUT DATA DEMAND (ODD) 



MLIA INPUT LINE FRAME 



SPARE 



HARDWARE BREAKPOINT 



OPS LEVEL PROGRAMS (OPERATION BELOW THE LOWEST INTERRUPT LEVEL) 



must be coded to handle restoration of other necessary 
information, such as local variables, program return 
address, program initialization and formal parameter 
linkage. Saving all this information would normally 
require the TIP vi^-iter to have an intimate knowledge of 
the compiler generated code; however, coding conventions 
are employed to avoid the need for such knowledge. 

There are sixteen interrupt levels in the CCP system, and 
a seventeenth (lowest) level called the OPS-level. The 
TIP is coded to permit all its PASCAL subroutines to 
execute at the same interrupt level (OPS-level). (Note, 
however, that a TIP can have one or more independent 
PASCAL routines that are coded to execute on Mux-2 
level. This is explained elsewhere.) Table 9-1 shows the 
interrupt levels of the standard CCP system. 

The OPS-level TIP retains control of the processor until it 
voluntarily relinquishes control to the system. This allows 
the TIP to use local variables without being concerned 
about their destruction until control is relinquished. 
Therefore, the TIP saves only those local variables that 
will be needed after reentry. This convention allows the 
TIP to be compiled by PASCAL without specifying the 
PASCAL reentrancy compiler option. The compiler uses 
this option to create and to use its own local variables. 

The compiler uses two registers (Rl and R2) in the 
generated code. These registers are initialized by a WITH 
statement of a pointer variable or a formal parameter. 



The code assumes the correct content of these registers 
within the domain of the WITH statement. If three or 
more WITH statements are nested, the compiler creates 
local variables for use as substitute registers. To simplify 
these conditions, the convention is adopted to close all but 
two WITH statements prior to making an exit for for a 
subsequent reentrance. Further, the rule of closure is 
invoked if a procedure is called w/hich ultimately exits for 
a subsequent reentry. If one or two WITH statements are 
not closed, they are always the WITH of the LCB and the 
TCB, in that order. This rule defines the contents of Rl 
and R2 for all modules. 

The convention of using the TCB and the LCB is arbi- 
trary. The TIP writer can use any other specification. 
However, it is convenient to always use a fixed constant 
for these registers. 

If a procedure which exits for subsequent reentry is called 
from more than one place, the return address must be 
saved. This return address may be obtained by the 
PASCAL procedure RETADR. The TIP must save this 
adddress in table space associated with the terminal, 
usually in the TIP defined area of the TCB. 

If a procedure uses a WITH statement of a pointer 
variable, the procedure entry code saves the current 
contents of Rl and R2. The initialization code uses local 
variables and restores the values of the last call to the 
procedure, not the values of the current caller. 
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Therefore, the TIP must execute code to return directly 
to the called procedure, thereby avoiding register 
restoration. This convention is used only if the values of 
Rl and R2 are always known to be the result of a WITH of 
the LCB and the TCB respectively. The restoration of 
registers may be avoided by defining a procedure which 
executes the PASCAL procedure RETURN without 
specifying a WITH statement. 

The register restoration avoidance procedure is as follows: 



PROCEDURE (special exit )((return address): 

INTEGER) : 
BEGIN 

RETURN (retumaddress); 
END; 



The following is an example of the use of the procedure: 



PROCEDURE (tip module); 
BEGIN 

MITH(tcbpointer)+.BSTCB, 
(lcl^ointer)tDO 

BEGIN 

RETADR (< return addre ss >) ; 



TCB POINTER 
LCB POINTER 

PROCEDURE RETURN 



END; WITH (tcbpopinter) 
(special exit)(<retum address>); 
END; (tip module) 



Formal parameters cause the use of local variables and 
cannot be referenced following an exit for subsequent 
reentry. Therefore, all return parameters must be passed 
back to the calling procedure in dynamic tables such as 
the TCB. Further, all references to the content of formal 
input parameters must precede the exit. This rule 
normally results in passing only the TCB and the 
specification of the TCB in the WITH as the first 
statement. 

The principal characteristics of exiting for subsequent 
reentry are as follows: 



Procedure name: PTSVILCB or PTSV2LCB 

Input parameter: (HALCBPCHLOPS] ) = LCB address 

Return parameter: none 

Calling sequence: PTSVILCB 
PTSV2LCB 



executing the reentry. 

The principal characteristics of executing a reentry are as 
follows: 



Procedure name: PTRTILCB or PTRT2LCB 

Input parameter: (HALCBP[HLOPS] ) = LCB address 

Return parameter: none 

Calling sequence: PTRTILCB 
PTRT2LCB 

Example of call: 

WITH (tcbpointer)+.BSTCB, 

(lcbpointer)+.DO 
BEGIN 

PTRTILCB; Reenter the TIP module 

END; 

IVT COMMAND PROCESSING 

When the TIP detects either an upline or downline 
interactive virtual terminal (IVT) command, the TIP calls 
function PTIVTCMD to check the syntax of the request 
and to process the command. If the command is entered 
from a terminal, PTIVTCMD decodes the command and 
changes the appropriate fields in the IVT parameter area 
of the TCB. On return, a reply to the terminal operator is 
provided in IVT format. The TIP will subsequently convert 
and transmit this information to the terminal. PTIVTCMD 
performs similar processing for downline commands from 
a host application program, but in this case the reply to 
the host takes the form of a BACK or BRK block. If the 
command was accepted, a BACK block is sent; otherwise, 
a BRK block is sent upline. 

The function PTIVTCMD returns a boolean value to inform 
the TIP whether the command was accepted or not. A 
value of TRUE indicates that the command was valid. 
The TIP must initialize any internal or external conditions 
which are affected by the IVT parameter. The specific 
IVT command and the communications line adapter or 
terminal define the actual process to be performed. For 
most TIPs, nothing is required. The buffers containing the 
command are always released, whether or not the 
command was accepted. 

The TIP is not informed which IVT command was 
detected. If any IVT command causes changes to internal 
tables or to the communications line adapter, the TIP 
must perform all the actions for any command. 

The principal characteristics of a call to PTIVTCMD are 
as follows: 



Example of call: 

PTSVxLCB; Wait for event 



At some later time, the TIP receives control from the 
system to process the worklist, which indicates that the 
awaited event has occurred. The TIP must recognize this 
solicited worklist so that it can call the reentrancy 
procedure PTRTILCB or PTRT2LCB. These procedures 
transfer control to the subroutine which last executed the 
related PTSVILCB or PTSV2LCB procedure. The contents 
of registers Rl and R2 are not altered. Therefore, the 
TIP must specify the WITH of the LCB and TCB prior to 



Procedure name: 
Input parameters: 



PTIVTCMD 

(source) = source of command 

C9TERM = upline comnand 
from terminal 

C9APPL = downline conmand 
from application program 

(BIBUFF) = address of data 
buffers holding the command 
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Return parameters: (PTIVTCMD) = BOOLEAN 
condition of results: 

TRUE = command accepted 
FALSE = command rejected 

(BIBUFF) = pointers to the 
buffers with reply to 
terminal for an upline 
command, in IVT format. The 
internal block flag 
(BFINTBLK) is set TRUE. 

Calling sequence: (result) = PTIVTCMD (source); 

Example of call : 

VAR 

(result) : BOOLEAN; COMMAND RESULT 

BEGIN 

BIBUFF := (huff erpointer) ; BUFFER WITH 

COMMAND 
(result) := PTIVTCMD (B9TERM); PROCESS 

COMMAND 
END; 



STATISTICS 

The system accumulates line and terminal statistics for 
periodic reports to the host's engineering file. Statistics 



are normally gathered by the POI procedures PBPOPOI 
and PBPIPOI for downline and upline traffic respectively. 
The TIP must also gather error statistics. For each block 
which had errors that required retransmitting the block, 
the TIP calls PNSGATH to record the event. 

The principal characteristics of a call to PNSGATH are as 
follows: 



Procedure name: 



PNSGATH 



Input parameters: (tcbpointer) = address of TCB 
(buffer pointer) = NIL 
(statistics type)=JOBADBLK 

Return parameters: none 

Calling sequence: 

PNSGATH( ( tcbpointer ) , (buff erpointer) , 
( statistic stype)); 

Example of call: 

VAR 

(tcbpointer) : BOBUFPTR; TCB ADDRESS 
BEGIN 

(tcbpointer) := (buffer address); 

PNSGATH ( (tcbpointer ) ,NIL , JOBADBLK) ; 
END; 
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The CCP operating system has several subroutines which 
provide services for the TIP. The TIP calls these sub- 
routines directly, or directly references tables and vari- 
ables kept by these subroutines. The services are as 
follows: 

• Placing the TIP into control with a worklist- 
defined task. The base system initiates TIP exe- 
cution and provides a work area for the worklist. 

■ Providing queuing of TIP-generated worklists, to 
itself, or to other OPS-level modules 

• Assignment and release of buffers 

• Timing services 

a Finding the address of a line control block from 
the line number 

TIP EXECUTION STARTED BY A 
WORKLIST 

At the OPS level, the operating system monitor places the 
TIP into execution when that TIP is the next module on 
the OPS-monitor worklist table, and the TIP has a worklist 
queued to it. The OPS monitor scans the worklist control 
blocks for all OPS-level entry modules on a round robin 
basis, so that all of these procedures have equal priority. 

Before placing the TIP in control of the NPU, the monitor 
moves the worklist entry into a global variable. The 
global variable is a complex type. Two of its variants 
apply to TIPs: one of these is for OPS-level entries, the 
other is for Mux-2 level entries. The two types of 
worklist entries used for TIPs are shown below. Since it is 
not possible to determine which type of processing to use 
before the workcode field is decoded, the TIP uses the 
multiplex subsystem overlay exclusively. The SVM data 
structure overlay is used when the TIP sends a worklist to 
the service module. 

OPS-level reference to the worklist is as follows: 



END; 



(wc) := MMWKCOD; 



END; 



SENDING A WORKLIST ENTRY 

The TIP calls PBLSPUT to send a worklist entry to the TIP 
itself or to another subsystem such as the service module. 

The principal characteristics of a call to PBLSPUT are as 
follows: 



Proceclure name: 
Input parameters : 



Return parameters: 
Calling sequence: 
Example of call: 



PBLSPUT 

(WLEptr) = Address of 
worklist entry 

(WLCBpointer) = Address of 
the worklist control block 

none 

PBLSPUT( WLEptr , WLCBptr ); 



WITH BWWLENTRYCOPS].CMSMLEY DO 
BEGIN 

CMWKCODE : = (wc) 

CMDATA : = (data) 
END; 
PBLSPUT (BWWLENTRYCOPS] , 

BYWLCB[BOSMWL]); 



Type of worklist 



Generate a 
worklist for 
the service 
module 



Note that the TIP is needed to set the worklist fields prior 
to calling PBLSPUT. 



VAR 

(wc) : INTEGER; 
BEGIN 

WITH BWWLENTRY[OPS].CMSMLEY DO 

BEGIN 

(wc) : = CMWKCODE; 

END; 
END; 



Mux-2 level reference: 



VAR 

(wc) : INTEGER; 
BEGIN 

WITH BWWLENTRY[MUX2].B0EWLQ DO 

BEGIN 



Workcode 



Workcode 



BUFFER MANAGEMENT 

The base system provides subroutines to assign and release 
buffers for the TIP. 



ASSIGNMENT OF A BUFFER 

The TIP may need to create messages or table structures 
in buffers. The TIP calls PBGETIBF to assign a buffer for 
such a specific function. PBGETIBF returns the address 
of the buffer which has been reserved for the TIP. 

The call to PBGETIBF to assign a buffer is as follows: 
VAR 

(bufptr) : BOBUFPTR; Buffer address 

BEGIN 

(bufptr) : = PBGETlBF(bufsize); 
END; 
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Bufsize is a set of system defined global variables. The 
use of any sized buffer but those that are system defined 
causes a system halt. The sizes are as follows: 

Size 



Variable 


c 


BOSS 


8 word buffer 


BOS 16 


16 word buffer 


B0S32 


32 word buffer 


B064 


64 word buffer 


BEDBSIZE 


Data buffer size 


BETPSIZE 


TPCB buffer 




control block 



size; text processing 



Bufptr contains the assigned buffer address when control 
returns to the TIP. Note that most data buffer assign- 
ment is done for the TIP, both during text processing and 
during input state program processing. In both cases, the 
firmware program (text porcessor or input data processor) 
does the buffer asignment. 



BUFFER RELEASE 

Two base subroutines are provided for releasing buffers; 
one for releasing a single buffer, and the other for 
releasing a chain of buffers. 



buffer size in bufsize, this will cause destruction of 
memory, and lead to an eventual system halt. 

NOTE 

Use of PBRELZRO protects against any 
attempt to release a nil bufptr. 



TIMING SERVICES 

The base system provides two timing functions for user 
written TIPs. These are: 

■ A variable containing a one second clock which 
the TIP can reference to measure timed intervals. 

• An array of decremented timers with an entry for 
each line in the system. 



ONE SECOND CLOCK 

The system variable CASECNTR is incremented once a 
second by the base system timer. This INTEGER type 
variable is set to zero during system initialization and is 
never reset. The time recycles to zero at 65,536 seconds. 



. Single Buffer Release 

The TIP calls PBRELIBF to release a single buffer. The 
calling procedure is as follows: 



Address o£ buffer 



VAR 

(bufptr) : BOBUFPTR; 
BEGIN 

PBRELlBF((bufptr), (bufsize)); 
END; 



Bufptr must contain a valid buffer address. Bufsize must 
be one of the valid system global variables defined for 
buffer size (see above). 

If the buffer that is being released has other buffers 
chained to it, only the first buffer in the chain is 
released. The address of the next buffer in the chain is 
returned in the bufptr parameter. If the TIP passes a bad 
address to PBRELIBF in bufptr or a bad buffer size in 
bufsize, this will cause destruction of memory, and lead to 
an eventual system halt. Note that bufadr equal zero is 
valid for PBRELZRO but invalid for PBRELIBF. 



Release of a Chain of Buffers 

The TIP calls PBRELZRO to release a chain of buffers. 
Format of the call is as follows: 

VAR 

(bufptr) : BOBUFPTR; Address of first buffer 

BEGIN 

PBRELZRO((bufptr), 
(bufsize)); 
END; 



Bufptr contains the address of the first buffer in the 
chain. Bufsize contains the size of each buffer in the 
chain (chained buffers are always uniform in size). It 
must be one of the globally-defined buffer sizes. 

On return to the TIP, bufptr always will be nil. If the TIP 
passes PBRELZRO, a bad address in bufptr, or a bad 



LINE TIMER 

The line timer provides a set of functions so the TIP 
vwiter can time line related events. The timer control 
table is an array indexed by port number. The port 
number is obtained from the line control block. Each 
entry in the array is of the form: 



15 14 


7 


BLRESET 


BLTIME 



The timing routines scan the table for a nonzero value for 
each enabled line in the system. Each half-second the 
timer decrements the value in BLTIME until the value 
reaches zero. At that time the system sends a timer 
worklist (AOTIMOUT) to the TIP that controls the line. 
The TIP can set the BLTIME value at any time by placing 
a nonzero value in the field. The TIP can cancel the timer 
at any time by setting BLTIME to zero. 

If the TIP sets a nonzero value in BLRESET, the multiplex 
subsystem will transfer this value to BLTIME (thereby 
starting the timer), whenever output is successfully sent 
over the line. This feature is useful for TIPs, which 
support a half-duplex protocol where a terminal response 
to the output block is expected to begin within a fixed 
interval, such a two seconds. An input state instruction 
can set BLTIME to zero or to a larger value once the first 
input character has been returned from the terminal. The 
system never changes the value in BLTRESET. 

The following example shows a use of the line timer: 



( rs t ime ) 


= (rstvalue); 


Link turnaround time 


(setime) 


= (setvalue); 


Timer interval 


VAR 






(Icbptr) 


: BZLCBP; 
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BEGIN 

WITH HALCb|hLOPs|+, 

BLTIMTBL+lport] DO 
BLTIME : = (setvalue); Starts the timer 
BLTREST : = (rstvalue); Set turnaround time 
BLTIME : = 0; Clear timer 

END; 

The line timer is often used to assure that an expected 
event occurred. If the TIP is waiting for an expected 
event that will generate a worklist, the timer can be 
started to time the event (note that an expected event 
and a soliticited worklist are different terms for the same 
action). If the timer worklist entry is received by the TIP, 
the expected event failed to occur. If the expected event 
worklist is received by the TIP, the event did occur during 
the permitted period. 

Since line inputs or outputs are usually the events to be 
timed, the TIP can set flags in the LCB which can be 
referenced by the system to terminate input and/or output 
before sending a worklist to the TIP. This feature is 
selected by setting boolean values in the LCB to true, as 
showm below: 



MMWTCOUNT is not equal to BZWTCOUNT. If, however, 
the expected event worklist follows the timer worklist, 
the former worklist cannot be detected as the timed 
event. Use of the routines PTSVILCB and PTSV2LCB 
causes the LCB value, BZWTCOUNT, to be incremented. 
Caution should be exercized for handling any reentrancy 
conditions for an expected worklist following a timeout 
worklist. Most conditions can be avoided by using the 
terminate input and terminate output features of the 
timeout event. However, it is also possible to generate a 
TlP-defined continue worklist in the TlP's own queue. 
Then the TIP can discard any expected event worklists 
until the continue worklist is received. Note that the TIP 
must not discard any other worklist entries; other worklist 
entires must be processed normally. 

LINE CONTROL BLOCK (LCB) 
ADDRESS 

The TIP calls the base subroutine PBLCBP to find the 
address of the line table when the TIP has the line number. 

The principal characteristics of a call to PBLCBP are as 
follows: 



VAR 

(Icbptr) : BZLCBP; 
BEGIN 

WITH (Icbptr) + DO 

BEGIN 

BZINPUT : = TRUE; 



BZOUTPOT : = TRUE; 



LCB address 



Terminate input on 
timeout 

Terminate output 
on timeout 



END; 



END; 



It is possible for an expected event to occur before the 
timer is cancelled. This causes both worklists to be sent: 
the timer worklist, and the expected event worklist. To 
take care of this condition, the timeout worklist can be 
marked with a sequence number, BZWTCOUNT, supplied 
by the TIP in the LCB. This value is placed in the 
MMWTCOUNT field of the worklist. If the TIP incre- 
ments BZWTCOUNT wrfien the timer is cancelled, the 
timer worklist can be discarded as extraneous, since 



Procedure name: PBLCBP 

Input parameter: (lineno) = Line number 

Return parameter: (LCBptr) = Address of LCB 

Calling sequence: PBLCBP((lineno) , (LCBptr)); 
Example of call: 
VAR 



Address of LCB 
Line number 



(LCBptr) : BZLCBP 

(line no) : INTEGER 
BEGIN 

PBLCBP((lxne no) , Ocbptr)) ; 
END; 



The line number is usually specified for the TIP by the 
worklist entry. 
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MULTIPLEX SUBSYSTEM 



11 



The multiplex subsystem contains the hardware, micro- 
programs, and software elements necessary to provide 
data and control paths for information interchange be- 
tween the TIPs and all communications lines. Design of 
the subsystem is based on the multiplex loop concept, 
which is a demand-driven system for gathering input data 
and status from the communications lines, and distributing 
output data and control information to the commu- 
nications lines. All of this is done on a real-time basis. 
Figure 11-1 shows the basic elements of the multiplex 
subsystem. 

A major purpose of the multiplex subsystem is to transfer 
the task of processing lines according to physical char- 
acteristics from the TIPs to the multiplex subsystem pro- 
grams. The TIPs need only command the multiplex 
siijsystem according to the logical characteristics of a 
line; the physical characteristics are handled by the 
multiplex subsystem and are transparent to the TIPs. 

Line-oriented input and output buffers provide temporary 
storage for data. The input data is placed in the circular 
input buffer (CIB) from which it is later extracted 
(demultiplexed), transformed to IVT/BVT ASCII format by 
the appropriate TIP, and moved into a line-oriented input 



buffer. The part of the TIP that does this (called input 
state programs) is controlled by the multiplex subsystem. 
The OPS-level TIP informs the command driver where the 
programs are located; the multiplex subsystem's input 
processor controls execution of the input state programs. 

Output data is read by the output processor from an 
output data buffer. The address of this buffer and other 
transfer information is supplied by the OPS-level TIP to 
the command driver. Data is in terminal format. 

The multiplex subsystem is event-driven by interrupts: an 
output data demand (ODD) for the next character of 
output data, or the input line frame received interrupt 
which indicates that data (and possibly CLA status) is 
contained in the CIB ready for demultiplexing. 

The interrupts are handled with global information stored 
in various tables. The subsystem processes data on a 
character-by-character basis while TIPs process data on a 
message or block basis. Circuit, modem, and subsystem 
status is detected and transferred to the TIPs using 
OPS-level worklist calls. Control information is received 
from the TIPs in the form of a call to the command driver 
with an attached command packet. This command packet 
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Figure 11-1. Basic Elements of the Multiplex Subsystem 
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is used to set up the multiplex LCB (NCLCB), which is the 
principal table used to control the transfer. 

HARDWARE COMPONENTS 

The multiplex subsystem includes the multiplex loop 
interface adapter (MLIA), loop multiplexers, and com- 
munications line adapters (CLAs). 

MULTIPLEX LOOP INTERFACE ADAPTER 

The MLIA provides hardware interface between the 
multiplex input/output loops and the multiplex subsystem 
software. The major functions are as follows: 

• Management of the I/O loops 

■ Input data buffering - compensates for the dif- 
ference in rate at which characters are removed 
from the input loops and the rate at which they 
are stored in the main memory 

• Output data demand (ODD) detection and buffering 

■ Multiplex loop error detection 

■ Generation of interrupts for the multiplex sub- 
system microprograms and software for functions 
such as: 

- Output data demand received 

- Line frame received 

- Loop error conditions 



multiplex loop. Its primary function is to receive parallel 
data from the CLAs and present it to the serial input loop 
in the loop cell format. Conversely, it assembles serial 
data in the loop cell format from the output loop and 
presents it to the CLAs in parallel form. 



COMMUNICATIONS LINE ADAPTERS (CLA) 

The CLAs provide the interface between the loop multi- 
plexers and the communications lines. The primary func- 
tions of the CLAs are to assemble serial data from the 
communications tine into parallel data and present this 
data to the loop multiplexer or, conversely, to disassemble 
parallel data from the loop multiplexer and present it in 
serial form to the communications line. The CLA oper- 
ating characteristics can be altered under program control 
for such functions as signal rate, character length, parity, 
and stop bit duration. 



TIP INTERFACES 

The multiplexer interface to the TIPs is defined in the 
following paragraphs. 

A TIP is a multilevel program that executes at three 
processing levels: 

• Multiplex level 1 (firmware or microcode level) 
■ Multiplex level 2 (macrocode level) 

• OPS level (processing to satisfy network protocol 
such as service message handling and timing) 



LOOP MULTIPLEXERS 

Each loop multiplexer provides an interface between a 
group of as many as 32 CLAs and the demand-driven 



MULTIPLEX LEVEL 1 - INPUT STATE PROGRAMS 

All incoming characters are processed by the multiplex 
subsystem, as directed by the input state programs. These 



TABLE 11-1. MUX-2 LEVEL WORKCODES 



Work code 



HMOBT 



MMFES 



MMBREAK 



MMCHOUT 



AOWKl to 
A0WK31 



MMBUTCH 



Description 



If the output buffer terminate flag (BJOBT) is set in the TlP-type table, the multiplex 
subsystem will send this workcode upon completion of each output block. The TIP uses 
this workcode as a trigger to start another output, thereby assuring maximum line 
utilization. All text processing of output data must be done at the OPS level, and not 
in response to this workcode. 



If an asynchronous CLA reports a framing error status, this workcode is sent to the TIP. 



If an asynchronous CLA reports a break, and the break condition is maintained for more 
than 200 ms , the multiplex subsystem sends this workcode to the TIP. 



This workcode is sent to the TIP when the character timer expires, 
resolution of 100 ms and is used only with asynchronous CLAs. 



The timer has a 



The tip's input state programs can send a workcode to the Mux-2 level procedure with one 
of these user-defined codes. This procedure can disrupt the system's normal 
multiprogramming methods. It should be avoided. 



When the system is critically low on buffers and a new buffer is required to process an 
incoming character, the TIP's input state programs are given control. A predefined 
state (state 3) is entered. This state can issue a MMBUTCH workcode to the TIP's 
level-2 procedure. The multiplex subsystem detects this workcode and releases all of 
this line's input buffers. It also stops processing of any other characters from other 
input lines. 
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Workcode 



AOHARDEER 



AOWKl to 
A0WK31 



TABLE 11-2. OPS-LEVEL WORKCODES 



Description 



The multiplex subsystem has detected an irrecoverable modem signal error The TIP 
should report a line failure to the host. 



The tip's input state program creates a worklist entry to send character-related event 
information to the OPS-level TIP. These codes are TIP-defined. 

These codes may also be used to indicate a terminate input or terminate output 



request . 



TIP-supplied programs direct the translation of terminal 
data into network data format. The input state programs 
are constructed of a special set of state programming 
language instructions which are interpreted by the input 
data processor of the multiplex subsystem. Usually, the 
entire translation of terminal data to virtual terminal 
format can be accomplished by the proper use of state 
programming instructions. The instructions for handling 
and generating these codes are described in detail in the 
State Programming Language Reference Manual. Table 
11-1 summarizes wori<code functions for Mux-2 level and 
table 11-2 describes the workcode functions for OPS level. 

MUX-2 LEVEL 

Each TIP can provide a procedure to receive control from 
the multiplex subsystem by means of a direct call. This 
procedure is to process high priority tasks. The OPS-level 
portion of the TIP can be interrupted to process the event 
leading to this priority call. Therefore, any procedures 
that are common between the OPS level and the Mux-2 
level of the TIP must be compiled with the reentrant code 
option selected. It is very desirable to avoid sharing 
subroutines between the two levels. 

The Mux-2 level procedure is entered for four system- 
defined events. The entry parameters appear in the form 
of a worklist, with the workcode and parameters con- 
tained in a work array, BWWLENTRY. The four system 
workcodes are defined in table 11-1. In addition, the TIP 
can send workcodes to its Mux-2 level procedure for user 
defined events. The worklist entries are entered in the 
multiplex subsystem event work list queue (MMEWLQ). 
Those worklist entries not recognized by the multiplex 
subsystem (AOWKl through A0WK31) are passed on to the 
TIP. Each input state instruction which creates a worklist 
(BLDWL and TIBWL) requires the address of the worklist 
control block owning the particular queue. This address is 
calculated by an MPEDIT expression which utilizes the 
worklist index. For the multiplex subsystem queue itself, 
the work list index used in the expression is MMEWLQ. 



OPS LEVEL 

The TIP must provide a primary entry point to receive 
control for all OPS-level worklist entries. These worklist 
entries are generated by any of several system modules as 
well as by the multiplex subsystem. The multiplex sub- 
system originates a worklist whenever it is requested to 
do so by one of the TIP's input state programs. These 
worklists indicate the occurrence of character-related 
events, such as the start of a message, the end of a 
message, the end of a line, or other protocol related 
events. Table 11-2 defines the workcodes sent to the OPS 
level by the multiplex subsystem 



COMMAND -DRIVER 

The TIP can issue commands to the multiplex subsystem 
to request the execution of an input, output, or control 
function for the line. These commands can be issued from 
either the OPS level or the Mux-2 level of the TIP. The 
commands indicate the type of function to be performed 
and are used to initialize user fields in the mux LCB which 
the TIP'S input state programs will need to use. 

The command driver procedure used by the OPS-level TIP 
is PBCOIN (general format of the command packet that 
accompanies the call is shown in figure 11-2); the pro- 
cedure used by the Mux-2 level TIP is PMCDRV. Two 
procedures are provided to avoid the complexities of re- 
entrant coding. 



WORD 


1 

2 

3 

4 

5 

6 


15 7 







Command 


Parameter 




Line Number 


Parameters 


Parameters 


Parameters 


Parameters 


Parameters 


7 


Parameters 







Figure 11-2. Command Packet General Format 



Principal characteristics of the command driver call are 
as follows: 



Procedure name: PBCOIN or PMCDRV 

Input parameter: (command packet) = Data 

record of type NKCMD with 
control and data parameters 

Output parameter: None 

Calling sequence: PBCOIN (conmand packet); 
PMCDRV (conmand packet); 

Example of a call: 

VAR 

(conmand packet) : NKINCOM; Command 

packet 



60474600 A 



11-3 



(output buffer) : BOBUFPTR; Address of 

output buffer 
BEGIN 

WITH( command packet) DO Set up 

output command 



NKCONTROL - Control line 



BEGIN 

NKCMD 

NKLINO 

NKOBP 



NKDOUT; Command code 
(line number); Line number 
(output buffer); Address of 
data 



END; 

PBCOIN( command packet); 



NKINPT 

NKDOUT 

NKINOUT 

NKENDIN 

NKENDOUT 

NKDISL 



Control Command 



- Input 

- Output 

- Input after output 

- Terminate input 

- Terminate output 

- Disable Line 



Initiate 
output 



END; 



The following commands are available to the TIP writer 
for controlling the flow of data to and from the com- 
munications lines: 



The control command (NKCONTROL) serves a twofold 
purpose. It can define the character transmission char- 
acteristics of a given line according to the terminal class 
(NKTCLS) for input/output signaling rate, character 
length, parity type, stop bit duration, and sync character. 
The command can also specify up to five modem/circuit 



Field 
NKCMD 
NKTCLS 

NKLINO 

Fl thru F5 
and NKFUNl 
thru KKFUHS 



NKZERO 



VOKD 


1 

2 

3 

4 



Type 
B08BITS 
B08BITS 

INTEGER 
BOOLEAN 



608 BITS 



15 


14 






7 


6 







NKCMD 






NKTCLS 








NKLINO 






Fl 


NKFUNl 


F2 


NKFUN2 


F3 


NKFHN3 


F4 


NKFUN4 


F5 




NKFUNS 




NKZERO 1 



Description 



Command code (NKCONTROL) 



New terminal class. If nonzero, the character parity, character length, and 
sync character are set up for this new terminal class from NJTECT. 

Line number 

Optional modem/circuit function; if the associated flag (NKSRFl - NKSRF5) is 
set, the function is to be implemented. 

1 = Function to be performed 
= Function disabled 

Delimits end of options. NKZERO is placed in the byte following the last 
requested modem/circuit function; five functions can be specified. 



OPTIONAL MODEM/CIRCUIT FUNCTIONS 



Function 


Function 






Mnemonic 


Provided 


Description 




NOBREAK 


BREAK 


Send break 




NOECHO 


ECHO 


Echoplex mode 




NOPON 


PON 


Parity on 




NOPSET 


PSET 


Parity set (1 = even, 


= odd) 


NOCLLS 


CLLS 


Character length (LSB) 




NOCLMS 


CLMS 


Character length (MSB) 





Pulsed functions provide momentary signal and need not be reset 



Figure 11-3. Control Command Format 
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control functions, such as echo, break, terminal busy, or 
resync. Such control functions are specified in the 
optional fields of the command packet. 

Generally, the command is used to initialize or alter the 
character transmission characteristics of the line or to 
generate circuit control functions. The control command 
format is as shown in figure 11-3. Optional modem/ 
circuit functions are defined in the figure. 



Input Command (NKINPT) 



The input command directs the multiplex subsystem to 
initiate the processing of data on the specified input line 
(i.e., to turn on the input side of the communications line 
adapter). The processing functions provided by the 
subsystem are determined by the input processing state 
program index. Additional information is passed by a 
pointer table address for the input processing states. If 



WORD 








1 






2 






3 






4 






5 






6 






7 


Field 


Type 




NKCMD 


B08BITS 




NKLINO 


INTEGER 




NKUOPS 


BOOLEAN 





FI 
F2 

NKISTAI 
F3 



BOOLEAN 
BOOLEAN 

B06BITS 
BOOLEAN 



F4 


BOOLEAN 


NKBLKL 


B012BITS 


NKISPTA 


INTEGER 


NKSCHR 


CHAR 


NKCNTl 


808 BITS 


NKCXLTA 


INTEGER 



15 


14 


11 




7 


6 


5 







NKCMD 


Not used 1 


NKLINO 








Not used 








NKUOPS 


Fl 


F2 




NKISTAI 


F3 


F4 


NKBLKL 


NKISPTA 1 


NKSCHR 


NKCNTl 1 


NKCXLTA 



Description 

Command code (NKINPT) 

Line number 

Eight user flags (NKUOPl - NKUOPS). NKUOPl is bit 15 in the MLCB user flag 
field,... NKUOPS is bit 8 in that field. NKUOPS is moved into MLCB if NKMVB 
is 1. 

NKMVB, move block of user flags into MLCB 

NKRPRT, strip parity flag; value must be specified: 

1 = strip parity I Actually, bit 7 of the character, 

= do not strip parity j whether it is parity or excess 

Input state program index; must be set 
NKNOXL, code translate flag 

1 = translate 

= do not translate 

NKSCENBL, change special character flag 

Character count 2. If nonzero, this sets the character count of the block and 
the initialization value. 

Pointer to input state program pointer table. If zero, the existing value is 
not changed. The original value is specified in NJTECT. 

Special character, moved to MLCB if NKSCENBL flag is set. 

Character count 1. If nonzero, character count 1 and its initialization value 
are set to this value. 

Code translation table address. If zero, the existing value is not changed. 
The original value is specified in NJTECT. 



Figure 11-4. Input Command Format 
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this option is not used, the information is taken from the 
terminal class table (NJTECT). Format of the input 
command is shown in figure 11-4. 



OUTPUT COMMAND (NKDOUT) 

The output command permits output messages to be 
directed to a specified output line. Line, modem, and 
control functions, as defined in the line type tables, are 
generated by the subsystem as a function of the physical 
line requirements. 

Output continues until the character specified by the last 
character displacement is transmitted. At that point, the 
subsystem chains to the next output buffer, if the chain 
address in the buffer is nonzero. Output stops if the chain 
address is zero or if the suppress chaining flag 
(BFSUPCHAIN) is set in the flag word of the first output 
buffer. 

The subsystem generates an optional worklist entry for 
the user program for each data block output by the 
subsystem. 

The terminate output or the disable command can also be 
used to terminate output processing functions on a spe- 
cified line. Receipt of either command causes the sub- 
system to immediately cease all processing functions 
associated with the specified line. 

The format of the output command is shown in figure 11-5. 



WORD 


1 

2 

Field 

NKCMD 

NKLINO 

NKOBP 


15 


7 




NKCMD • 


Not used 




NKLINO 


NKOBP 


Type 

B08BITS 
INTEGER 
BOBUFPTR 


Definition 

Command code (NKDO 
Line number 
Output buffer poin 


UT) 
ter 



Figure 11-5. Output Command Packet 



Input After Output (NKINOUT) 

This command permits interactive terminals (such as a 
display/keyboard combination) to be immediately ready to 
receive input data in response to a message displayed at 



the terminal. An index to the input state process table 
indicates the treatment of the returned data. The format 
for this command is shown in figure 11-6. 

If the buffer output is the last data buffer of a 
transmission block, and line turnaround is required, (1) the 
subsystem generates the proper modem control signals to 
turn the line around, (2) monitors modem status for line 
turnaround, and (3) notifies the appropriate terminal- 
dependent subroutine that the line is ready for input. 
Modem signals and modem status analysis functions are 
specified by the line-type tables. 

Terminate Input Command (NKENDIN) 

This command enables the TIP to direct the multiplex 
subsystem to immediately stop input processing functions 
on the specified line. Buffers are optionally discarded. 
The TIP program can, by issuing an input command, direct 
the subsystem to resume input on the line. Transmission 
line characteristics are not altered by the terminate input 
command and, therefore, the TIP need not generate a 
control command. The format for the terminate input 
command is shown in figure 11-7. 

After processing the terminate input command, the sub- 
system optionally generates a worklist entry to the TIP as 
specified in the worklist and workcode. 



Terminate Output Command (NKENDOUT) 

This command enables the TIP to direct the multiplex 
subsystem to terminate output processing functions on the 
specified line immediately. After processing the termi- 
nate command, an optional worklist entry is generated to 
the TIP, using the specified worklist and workcode. This 
command is used when the TIP interrupts an outgoing 
message for a higher priority message, or when an abnor- 
mal line condition occurs. The format of the terminate 
output command is shown in figure 11-8. 



Disable Line Command (NKDISL) 

The disable line command directs the multiplex subsystem 
to terminate all processing functions of the specified 
line. Modem control signals are generated to inhibit 
further exchange between the local modem and the 
communications line. The subsystem also releases all data 
structures defining the character processing functions for 
the line. To reactivate the functions, a control, initialize, 
and enable command, followed by either an input or 
output command, must be issued. The format for the 
disable line command is shown in figure 11-9. 
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Field 
NKCMD 
NKLINO 
NKOBP 
NKOOPS 

Fl 
F2 



NKISTAI 
F3 

F4 
NKBIKL 

NKISPTA 

NKSCHR 
NKCNTl 

NKCXLTA. 



WORD 


1 

2 

3 

it 

5 

6 

7 



Type 
B08BITS 
INTEGER 
BOBUFPTR 
BOOLEAN 

BOOLEAN 
BOOLEAN 

B06BITS 
BOOLEAN 

BOOLEAN 
B012BITS 

INTEGER 

CHAR 
808 BITS 

INTEGER 



15 


14 


13 11 




7 6 


5 







NKCMD 


Not used 1 


NKLINO 


NKOBP 


NKUOPS 


Fl 


F2 


NKISTAI 1 


F3 


F4 


NKBLKL 1 


NKISPTA 1 






NKSCHR 




NKCNTl j 


NKCXLTA 



Description 

Command code (NKINOUT) 

Line number 

Output buffer pointer 

Eight user flags (NKUOPl - NKUOPS). NKUOPl is bit 15 in the MLCB user flag 
word; NKUOPS is bit 8 in that word. NKUOPS is moved into MLCB if NKMVB is 1. 

NKMVB, move block of user flags into MLCB 

NKRPRT, strip parity flag; value must be specified: 

1 = strip parity 

= do not strip parity 

Input state program index; must be set 
NKNOXL, code translate flag 

1 = translate 

= do not translate 

NKSCENBL, change special character flag 

Character count 2. If nonzero, this sets the character count of the block and 
the initialization value. 

Pointer to input state pointer table. If zero, the existing value is not 
changed. The original value is specified in NJTECT. 

Special character, moved into MLCB if NKSCENBL flag is set 

Character count 1 . If nonzero, the character count 1 and its initialization 
value are set to this value. 

Code translation table address. If zero, The existing value is not changed. 
The original value is specified in NJTECT. 



Figure 11-6. Input after Output Command Format 
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Field 
NKOfl) 
Fl 
F2 
NKWLINDX 

NKLINO 

NKUSRBY 

NKWKCOD 



Field 
NKCMD 
Fl 

F2 
NKWLINDX 

NKLINO 

NKUSRBY 

NKWKCOD 



WORD 


1 

2 



15 






7 


6 


5 







NKCMD 


Fl 


F2 




NKWLINDX 


I 


NKLINO J 


NKUSRBY 


NKWKCOD 



Type 
B08BITS 
BOOLEAN 
BOOLEAN 
BOWKLSfS 

INTEGER 
B08BITS 
NKWKCOD 



Description 

Command code (NKENDIN) 

NKRELBFS, release buffer flag (release buffer if set) 

NKWKFL, send worklist to user (if set) 

Worklist index, used if NKWKFLG is set. The TIP uses one of the user-defined 
values BOVWLl through B0VWL4. 

Line number 

User-supplied byte, returned in field MMWTCOUNT in worklist 

User workcode in worklist (MMWKCOD). One of the values AOMKl throu^ A0WK31 
is used. 



Figure 11-7. Terminate Input Command Format 



WORD 


1 

2 



15 






7 


6 


5 







NKCMD 


Fl 


F2 


NKWLINDX " 1 


NKLINO 1 


NKUSRBY 


NKWKCOD 



Type 
B08BITS 
BOOLEAN 

BOOLEAN 
BOWKLSTS 

INTEGER 
B08BITS 
B08BITS 



Description 



Command code (NKENDOUT) 



NKRELBFS, releases buffer when flag is set; these are buffers specified in 
BZLBTOMUX 

NKVnCFLG, sends worklist to user when set 

Worklist index; used if NKWKFLG is set. The TIP uses one of the user-defined 
values BOVWLl theough B0VWL4. 

Line number 

User-supplied byte to be returned in field MMWTCOUNT in worklist 

User workcode in worklist (MMWKCOD). One of the values AOWKl throu^ A0WK31 
is used. 



Figure 11-8. Terminate Output Command Format 



15 




7 







NKCMD 


Not used 1 




NKLINO 




J 



Field 

NKCMD 
NKLINO 



TZEi 



Description 



B08BITS Conmand code (NKDISL) 

INTEGER Line Number 



Figure 11-9. Disable Line Command Format 
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12 



Virtual terminal format allows host application programs 
to expect only two types of input: ASCII input from a 
standardized interactive terminal (IVT), or ASCII input 
from a standardized batch terminal (BVT). 

Each TIP is responsible for converting terminal code and 
format to and from ASCII virtual terminal formats. 
Downline, this is handled entirely by text processing state 
programs. If the TIP handles several types of terminals 
with dissimilar characteristics, the TIP will probably need 
one set of state programs to handle the conversions for 
each terminal type. 

Since the techniques to format for IVT and BVT have little 
in common, the two types of terminals are discussed 
individually. 



BATCH VIRTUAL TERMINAL (BVT) 

Batch virtual terminal provides the standard interface 
which permits application programs in the host to ex- 
change information with remote batch terminals, without 
regard to specific terminal characteristics. 



BATCH VIRTUAL TERMINAL CHARACTERISTICS 

The BVT is deemed to be a multi-device terminal 
operating remotely from the host. BVT is connected to 
the NPU by a synchronous modem using a medium speed 
or high speed line. (Although the protocol on the line may 
differ by equipment type, BVT is always assumed to be a 
block transfer terminal). 

A separate logical connection exists for each device on a 
line. Device types that can exist at remote terminals 
include card readers, printers, plotters, and card punches. 

BVT is capable of supporting data compression, printer 
carriage control, code conversion, transparent data, mode 
control, and file structure. For downline blocks, the host 
process assured that downline network blocks are not 
longer than the allowable block size for the terminal 
device, allowing space for TIP-inserted control infor- 
mation. The host application program must also assure 
that the width of an output print line does not exceed the 
device's Printline width. 

The host process is also responsible for compressing data. 
Downline, only blank and zero compression is allowed. 
Any other type of attempted compression will cause the 
block to be rejected by a BRK block from CCP. The 
terminal determines the degree of upline compression 
allowed. Full compresaon is assumed. 

The BVT data is contained within MSG and BLK blocks; 
the CMD blocks are used to pass BVT command infor- 
mation. The standard remote batch facility (RBF) uses 
the BVT data format and defines the sequence of block 
types for transferring data and control. Since a user- 
defined batch TIP can be designed to accept data connec- 
tions with RBF, the rules for RBF are discussed here. 



SUMMARY OF RBF RULES 



Control Console and Batch Devices 

RBF assumes that a batch terminal consists of one or 
more batch devices (such as a card reader or a printer) 
and an interactive console. The interactive console pro- 
vides any control commands necessary for RBF operation. 
The interactive console uses the IVT interface. It is 
possible to simulate all the necessary RBF control com- 
mands that are normally provided by an interactive 
console, by use of control functions entered through a 
card reader. The TIP must separate the control infor- 
mation from the batch card input and send the control as 
IVT data on the simulated console connection. 

Batch Input 

Batch input from a card reader should not be started until 
a start input command is received from RBF. This 
command assures that RBF will accept the data and no 
information will be lost. Card reading can begin and 
network blocks can be constructed by the TIP. Usually, 
one transmission block is created for BVT and sent to the 
host as one network block. The TIP does not perform data 
compression. If the BVT syntax provides the appropriate 
representation, the TIP is not required to perform data 
expansion. The TIP should discard all trailing blanks on 
each card. 

If an end of information card (EOI) is detected in the 
upline transmission block, The TIP must fragment the data 
into one or more network blocks. The EOI card must be 
the last card of a MSG block. Subsequent EOI cards are 
discarded until a non-EOI card is detected. If such a 
non-EOI card is found, the remaining data is send to the 
host as the first block of the next message. 

Whenever the card reader has run out of source data and 
has informed the TIP of this condition, the TIP must 
generate an input stopped command to follow the last 
network block. This informs RBF that the input device is 
not ready. The TIP must await a start input command 
from RBF before card reading can resume. 

The input stopped command can also indicate a slipped 
card error. Either the slipped card or the end of source 
condition will cause RBF to generate a message to the 
batch terminal's console. 

A stop input command may be sent downline to the TIP as 
a result of an RBF command. In this case, the TIP must 
stop reading the cards, and must also send an input 
stopped command upline to acknowledge that the re- 
quested action was performed. The stopped input com- 
mand follows the last network block containing data. 



Batch Output 

The output data stream from RBF does not contain com- 
mands. A network output data block can be transformed 
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into a single transmission block and sent to the terminal. 
RBF must contain the necessary information so that it can 
create the proper sized and formatted network blocks. 

If an output device is not ready to receive data, the block 
is undeliverable and the TIP replies to the host with a 
BRK block. The BRK block's reason code prompts RBF to 
create a message for the interactive console which con- 
trols this device. It is assumed that the operator will 
enter the proper control commands so that output can 
resume. 



Output Block Size 

The TIP writer has two choices for defining network block 
construction for the new TIP: (1) he can modify RBF by 
adding a new set of rules suited to this TIP's terminal 
buffer sizes, or (2) he can cause the TIP to fragment a 
network block for the device into two or more trans- 
mission blocks. If the latter choice is made and the TIP 
has to generate a BRK block because the device was not 
ready, the TIP is responsible for saving the unprinted 
fragments. Normally, the TIP would assure that these 
unprinted fragments are neither duplicated nor lost. 
However, if such delivery assurance is not required, the 
fragments can be discarded. 

Line utilization is affected if the chosen fragment size is 
not the maximum size allowed by the terminal's buffers. 
It should be noted that the selection of block size is not a 
significant factor for low speed line utilization. 



Line Folding and Compression 

Line folding and compresaon of zeroes or blanks is 
performed by RBF. The TIP need not perform any further 
compression, but it is permitted to do so. Compresssion 
of characters in RBF can be suppressed if character 
compression is not supported by the terminal, or the TIP 
can perform character expansion prior to transmission. 

STP and STRT Blocks 

The STP block can be sent on a batch connection if the 
TIP needs to stop downline data or commands. The TIP 
must detect a restart condition and send a STRT block 
upline to indicate that the data stream has been 
restarted. This command sequence is especially useful 
when batch devices are physically dependent and cannot 
be used simultaneously. 



BVT SYNTAX 

Table 12-1 defines the syntax for BVT data and com- 
mands. The table is presented in a modified Bachus Naur 
format. The rules for this type of table are given on the 
first page of the table. Table 12-2 describes the print 
actions for the defined forms-control characters. All TIPs 
should support forms-control characters EO through E4. 
All other values can be treated as preprint single space, if 
the printer does not support paper motion functions. 



INTERACTIVE VIRTUAL TERMINAL 

The interactive virtual terminal (IVT) is defined to provide 
common interface-to-host application programs for a 
variety of interactive terminal types. The TIP is respon- 
sible for converting the IVT interface to the terminal's 
real characteristics, and the converse. The output trans- 
form is usually simple, as the IVT interface is defined for 



display characters and is not extended to the various 
control capabilities of physical terminals. The interface 
requires that specific functions be performed both upline 
and downline. The IVT syntax is described in table 12-3. 
This is also presented in modified Bachus Naur format. 
The rules for this format are given in table 12-1. 



DOWNLINE IVT TRANSFORM 

The TIP receives three types of downline blocks that are 
associated with IVT processing: BLK, MSG, and CMD 
blocks. BLK and MSG blocks contain data to be sent to 
the terminal. CMD blocks contain control information for 
the TIP. Host application programs originate all three 
types of blocks, as required. A BLK block indicates that a 
MSG block must follow to complete the message for the 
terminal. One or more BLK blocks can precede the MSG 
block. A MSG block can contain all of the message or 
only the final block of the message. 



Time of Transferring Downline Data 

The TIP translates the data in a downline IVT block to a 
format and code set that can be recognized by the 
terminal. The TIP can be designed in either of two ways: 
(1) the TIP can immediately send the data downline to the 
terminal and send an acknowlegement upline to the host 
that the data was sent, or (2) the TIP can collect blocks 
and wait until the MSG block is received before sending 
the data to the terminal. When the TIP receives a 
message block, it must send the data, since the network 
cannot assure the TIP that more data will follow. 

Downline data is normally to be translated into terminal 
format and code. However, it is possible for the host to 
send blocks of transparent data for the terminal. The TIP 
must send the transparent data to the terminal imme- 
diately; the TIP can neither fragment blocks nor collect 
blocks to send as a complete message. 



Downline Data Format 

Downline IVT data consists of one or more logical lines. A 
logical line consists of an optional format effector, a 
string of ASCII data or IVT control characters, and a 
terminator. Two conditions are possible for format 
effectors: either the format effectors are present in 
every logical line of a MSG or BLK block, or none of the 
lines contain format effectors. If a suppression bit is set 
in the data block clarifier (DBC), none of the lines have 
format effectors. 

IVT Format Effectors 

The host application program assumes that a given format 
effector always causes a consistant type of operation at 
each terminal. However, since some terminals inhibit 
certain operations, the TIP must provide default actions 
to cover these cases. Format effectors are described in 
table 12-4. 

For each input operation from a terminal, the TIP posi- 
tions the cursor to the first character position for the 
next line. 

NOTE 

In the following discussion, cursor posi- 
tioning should be taken to mean either 
positioning a true cursor (display symbol) 
or positioning of the next character to be 
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TABLE 12-1. BVT SYNTAX 



Following is a description of the metasymbols belonging to the BNF formalism used to describe 
IVT, BVT, block protocol, and commands. 



Symbol 

I 

<> 

( I 
I I 

* 

+ 
( ) 



Meaning 

This metasymbol indicates that the syntactic construct to the left is defined 
as the string or alternation of strings to the ri^t. 

The vertical line demarcates alternatives. 

The angular brackets enclose syntactic constructs denoted by English phrases. 

Braces enclose optional expressions. 

An asterisk exponent indicates zero or more repetitions. 

A plus exponent indicates one or more repetitions. 

Parentheses are used to factor alternatives or expressions formed from them. 



<BVTBLKDATA>i 

<BVTMSGDATA>i 

<UPLINEBVTBLK> 

<D0W1ILINEBVTBLK> 

<nPLINEBVTMSG> 

<DOWNLINEBVTMSG> 

<CARDREADERBLK> 

<CARDREADERMSG> 

<PRmTBLK> 

<PRINTMSG> 

<PUNCHBLK> 

<PUNCHMSG>2 

<PLOTBLK> 

<PLOTMSG> 

<UPLINECARD> 

<PRINTLINE> 

<DOWNLINECARD> 

<PLOTLINE> 

<CARDREADEEDBC> 

<PRINTDBC> 

<PLOTDBC> 

<PnNCHDBC> 



<UPLINEBVTBLK> { <DOWNLINEBVTBLK> 

<UPLINEBVTMSG> | DOWNLINEBVTMSO 

<CARDREADERBLK> 

<PRINTBLK> I <PUNCHBLK> j <PLOTBLK> 

<CARDREADERMSG> 

<PRINTMSG> I <PUNCHMSG> { <PLO'mSG> 

<CARDREADERDBC> <UPLINECARD>* 

<CARDREADERDBC> <UPLINECARD> * <ENDOFINFORMATION> 

<PRINTDBC> <PRINTLINE>* 

<PRINTDBC> <PRINTLINE>* <ENDOFINFORMATION>j 

<PUNCHDBC> <DOWNLINECARD>* 

<PUNCHDBC> <DOWNLINECARD> * <ENDOFINF0RMATI0N> 

<PW)TDBC> PLOTLINE>* 

<PLOTDBC> <PLOTLINE> * <END0FINFORMATION> 

<CARDREADERDATA> | <ENIX)FRECORD> 

<PRINTDATA> I <ENDOFREC0RD>- 

<PUNCHDAIA> j <ENDOFRECORD> 

<PLOTDATA> j <ENDOFRECORD> 

X'OO 

X'OO 

X'OO 

<SPARE> <SPARE> <SPARE> <SPARE> <SPARE> <SPARE> 
<BABNERCARD> <SPARE> 
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TABLE 12-1. BVT SYNTAX (Contd) 



<SPARE>3 

<BANNERCARD>3 

<PUNCHBANNERCARD>3 

< DONTPUNCHBANNERC ARD >3 

<CARDREADERDATA> 

<PRINTDATA> 

<PONCHDAm> 

<PIjOTDAm> 
<UPLINECOMPRESSEI»ATA> 



<DOWNLINECOMPRESSEI»AT/V> 

<FORMSCONTROL>/f 

<C0MPRESSEDZERDS>5 

<C0MPRESSEDBLANKS>6 

< REPLICATI0NCOUKT>7 

<BYTE> 

<BVTESCAPE> 

<M0DECHANGE>8 

<ASCn029> 

<ASCII026> 

<STRING IND ICATOR>9 

<IND ETERM INATELENGTH STRINO 

< STRINGSEQUENCE > 

<DATAFF> 

<STRINGBYTE> 

<STRINGLENG1H>ii 

< FIXEDLENGTH STR ING > 

<END0FMEDIA>13 

<END0FREC0RD>i4 

<LEVEIHUMBER> 



<PUNCHBANNERCARD> j <DOKTPUNCHBANNERCARD> 

1 



<MODECHANGE> { <UPLINECOMPRESSEDDATA>* 
<ENDOFMEDIA> 

<MOD ECH ANGE> [ <FORMSC0NTR0L> 
<DOWNLINEDOMPRESSEDDATA>* <ENDOFMEDIA> 

<MOD ECHANGE > | <DOWNLINEC0MPR ESSEDDATA>* 



<ENDOFMEDIA> 



<MODECHANGE>| <IX)WNLINECOMraESSEDDATA>* 



'I 
<ENDOFMEDIA> 

<COMPRESSEDZEROS> I 

<COMPRESSEDBLANKS> I 

<REPLICATIONCOUNT> <BYTE>| 

<STRINGINDICATOR> <INDETERMINATELENGTHSTRING> | 

<STRINGLENGTH> <FIXEDLENGTHSTRING> 

<COMPRESSEDZEROS> \ 
<COMPRESSEDBLANKS> j 
<STRINGLENGTH> <FIXEDLENGTHSTRING> 

<BVTESCAPE> (X'EO|X'Elf ...|X'FE) 

<BVTESCAPE> (X'32|X'33l ...|X'3F) 

<BVTESCAPE> (X'X2lX'13| ...|X'2F) 

<BVTESCAPE> (X'Mf X'43j ... J X'8F) 

XOO I X'Ol ) ... I X'FF 

X'FF 

<ASCII029> 1 <ASCII026> 

<BVTESCAPE> X'OO 

<BVTESCAPE> X'03 

<BVTESCAPE> X'90 

+ 
<STRINGSEQUENCE> 10 

<DATAFF> I <STRINGBYTE> 

<BVTESCAPE> X'FF 

X'OO X'Ol ... X'FE 

<BVTESCAPE> (X'91 X'92 ... X'CF) 

n 
<BYTE> 12 

<BVTESCAPE> X'OA 

<BVTESCAPE> X'OB <LEVELNUMBER> 
<LEVEmUMBER> <ENDOFMEDIA> 

<BYTE> 
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TABLE 12-1, BVT SYNTAX (Contd) 



<ENDOFINFOKMAnON>i5 

< CMDBLKDA1A> 
<STOPINPUT> 

< SXARTINPUT> 

< INPUTSTOPPED> 

<CTRLPFC> 
<STOPINPUTSFC> 

< STARTINHITSFO 

< INPUTSTOPPEDSFO 

< INPUTSTOPPEmEASONCODE> 

< STOPINPUTRESPaiSE> 

< INRITDEVICEMOTSEADY> 
<CARDSLIPERROR> 
<EOIINPUT> 



<BVTESCAPE> X'OC <ENDOFMEDIA> 

<STOP INPUT> I <STARTINPUT>| <INPUTSTOPPED> 

<CTRLPFC> <STOPINPUTSFC> 

<CTRLPFC> <STARTINPUTSFC> 

<CTRLPFC <INPUTSTOPPEDSFC> 
<INPnTSTOPPEDREASONCODE> 

X'Cl 

5 

6 

7 

<STOPIIIPirTRESPONSE> | 
<INPDTDEVICENOTREADY> j 
<CARDSLIPERROR> j <EOIINPUT> 



1 

2 

3 



NOTES: 
1. 

2. 

3. 
4. 



9. 

10. 
U. 



<BVTBLKDATA> and <BUTMSGDATA> represent the data portion of a network data block, 
i.e., that portion of the block starting with the DBC. 

<ENDOFINFORMATION> should be required in a <PUNCHMSG> but the R4 syntax allows a 
<PUNCHMSG> consisting of <PUNCHDBC> only. 

These syntactic constructs represent a single bit. 

<F(»MSCONTRDL> which are not supported by a specific device result In a preprint 
single space. 

<COMPRESSEDZEROS> is used to represent 2 through 15 zeros. 

<COMHlESSEDBLANKS> is used to represent 2 through 31 blanks. 

<REPLICATIONCOUNT> is the number of times (2 through 79) the following character is 
to be repeated. 

Each device type supported by the BVT is assigned a data mode which, in most cases, 
is unchangeable. However, downline data to a card punch may contain a <MODE CHAHGE> 
requesting the TIP to perform the appropriate code translation to generate the 
desired punched cards. The mode selected stays in effect until the next <MODE 
CHANGE> or an <ENDOFINFORMATION>, which causes the data mode to be returned to the 
default for the device. For all other downline data and all upline data, <MODE 
CHANGE> is ignored. 

<ASCII-029> indicates that the data should be interpreted as ASCII, but that only 
the 64 character subset will appear. The data will be translated by the TIP to 
produce 029 cards. Similarly, <ASCII-026> will produce 026 cards. 

< STRING INDICAT(H> indicates a character string of 1 to 80 characters following which 
is terminated by the first non-data FF. 

A <STRINGSEQUENCE> is restricted to 1 to 80 characters. 

<STRINGLENGTH> indicates a character string following of 1 to 63 bytes. 



60474600 A 



12-5 



TABLE 12-1. BVT SYNTAX (Contd) 



12. 
13. 
lA. 

15. 



n represents repetition from 1 to 63 times based on the value of <STRINGLENGTH>. 

<ENDOFMEDIA> not preceded by data causes a blank record to be generated. 

<ENIX)FRECOED> causes a 789 card to be punched for card punch. It is ignored for 
printer or plotter. Upline the level numbers, represent the contents of columns 2 
and 3 of 789 card and columns 6 and 7 of a /*EOR card. 

<ENDOFINFOEMATION> is ignored in print and plot MSG blocks. It causes a /*EOI card 
to be generated for a HASP card punch. 



TABLE 12-2. FORMSCONTROL VALUES FOR BVT BLOCKS 





<F0RMSCOin:RDL> 
(HEX) 


Action Before Printing 


Action After Printing 






EO (1) 


Space 1 


No Space 






El (1) 


Space 2 


No Space 






E2 (1) 


Space 3 


No Space 






E3 (1) 


Suppress Space 


No Space 






E4 (1) 


Skip to Channel 1 f2) 


No Space 






E5 


Skip to Channel 12 (3) 


No Space 






E6 


Skip to Channel 6 


No Space 






E7 


Skip to Channel 5 


No Space 






E8 


Skip to Channel 4 


No Space 






E9 


Skip to Channel 3 


No Space 






EA 


Skip to Channel 2 


No Space 






EB 


Skip to Channel 11 


No Space 






EC 


Skip to Channel 7 


No Space 






ED 


Skip to Channel 8 


No Space 






EE 


Skip to Channel 9 


No Space 






EF 


Skip to Channel 10 


No Space 






FO 


No Space 


Skip to Channel 1 (2) 






Fl 


No Space 


Skip to Channel 12 (3) 






F2 


No Space 


Skip to Channel 6 






F3 


No Space 


Skip to Channel 5 






F4 


No Space 


Skip to Channel 4 






F5 


No Space 


Skip to Channel 3 






F6 


No Space 


Skip to Channel 2 






F7 


No Space 


Skip to Channel 11 






F8 


No Space 


Skip to Channel 7 






F9 


No Space 


Skip to Channel 8 






FA 


No Space 


Skip to Channel 9 






FB 


No Space 


Skip to Channel 10 






FC-FE Reserved 






Notes : 

1. Supported on all devices 

2. Page eject 

3. Bottom of page 
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TABLE 12-3. IVT SYNTAX 



<D0WNLINEC0NSOLEBLK> 

<UPLINECONSOLEBLK> 

<DOWNLINECONSOLEMSG> 

<UPLINECONSOLEMSG> 

<UPLINEFRA01ENT> 

<TRAN SPARENTFRAQ!ENT> 

<IVmiAGMENT> 

<UPLINEFR AGMENTEND > 

<DOW»JLINECONSOLELINES> 

<TRANSPARENTLINE> 

<UPLINEIVTL1SE> 

<DOWNLINEIVTLINES> 

<D0VniLINEIVTBYTE>5 

<HS> 

<CR> 

<IJF> 

<UPLINEIVTBYTE>5 

<BY1E> 

<K)RMATEFFECTOR>2 

<UPLraECONSOLEDBC > 

< SPARE > 
<I«TlfSED> 
<TRANSPARENT>3 
<CANCELLED> 

<PARITYERROR> 

<DATAISNOTTRANSPARENT> 
<DATAISTRANSPARENT> 

< PREVIOUSDATAISl«)TCANCELLED> 
<PREVIOUSDATAISCANCELLED> 
<DATARECEIVEDWITH01JTERR0R> 

< DATARECEI VEDWITHPARITYERROR> 

< DOWNLDJECONSOLEDBO 



<DOWNLINECONSOLEDBC> <DOWNLINECONSOLELINES> 

<UPLINECONSOLEDBC> <UPLINE ERAGMENT> 

<DOWNLINECONSOLEDBC> <DOWNLINECONSOLELINES> 

<UPLINECONS0LEDBC> <UPLINEFRAGMENTEND> 

<TRANSFARENTBRAGMENT> | IVTFRAGMENT> 

<BYTE>* 

<UPLINEIVTBYTE>* 

<TRANSPARENTFRAGMENT> | <IVTFRAGMENT> 

<TRANSPARENTLINE> | <DOWNLINEIVTLINES> 

<BYTE>* 

<OPLINEIVTBYTE>* 

(<FORMATEFFECTOR> <DOWNLINEIVTBYTE> * <US>)*| 
(<DOWNLINEIVTBYTE> * <0S>)* 

X'OO I X'Oll 
|X'1E f X'20J 

X'lF 

X'OD 

X'OA 

X'00( X'Ol j 

X'OO I X'Ol j 

<BYTE> 



X'09l X'OB |X'OC } X'Oe| ... 
j X'7E fX'7F |<CR> |<LF> 



( X'7E I X'7F 
I X'7E } X'FF 



<SPARE> <SPARE> <SPARE> <NOTOSED> 
<1I0T0SED> <TRANSPARENT> <CANCELLED> 
<PARITYERROR> 







<DATAISlIOTrRANSPARENT> | <DATAISTRANSPARENT> 

<PREVIOnSDATAISKOTCANCELLED> | 
<PREVIO0SDATAISCANCELLED> 

<DATARECEI VEDWITHOUTERROR> | 
<DATARECEIVEDWITHPARITYERROR> 



<SPARE> <SPARE> <SPARE> <SPARE> 
<FOEMATEFFECTORHSAGE> <TRANSPARENT> 
<PIOTUSED> <AUTOINPUT> 
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TABLE 12-3. IVT SYNTAX (Contd) 



<FORMATEFFECTORUSAGE> 
<AUTOINPUT> 

<FC»MATEFFECTORI SU SED> 

<FORMATEFFECTORNOTUSED> 

<OUTPUTI SAnTOINP0T>i6 

<OTTHJTISN0TAUTODIPUT> 

<CONSOLECMDD ATA > 

<I»VraLINEC™SOLECMD> 

<UPLINECONSOLECMD> 

<SroPINPUT> 

<STARTINPOT> 

<lVTCOMMAin)> 

<INPUTSTOPPED> 

<CTRLPFC> 

<STOPINPOTSFC> 

<STARTINPOTSFC> 

<TERMINALDEFINITIONSFC> 

<INPDTSTOPPEDSFC> 

<INPUTSTOPPEDREASONCODE> 

<STOPINPOTRESPONSE> 



<FORMATEFFECTORSUSED> \ 
<FORMATEFFECTORSNOTUSED> 

<OOTPUTI SAUTOINPUT> | 
<OUTPOTI SNOTAUTOINPUT> 



1 

1 



<DOWin,INECONS0LECMD> | <UPLINECONSOLECMD> 

<STOPINPUT> I <STARTINPOT> | <IVTCOMMAND> 

<INFUTSTOPPED> 

<CTRLPFC> <STOPINPUTSFC> 

<CTRLPFC> <STARTmPUTSFC> 

<CTRLPFC> <IVTCOMMAND> <IVTC(»IMANDTEXT>4 

<CraLPFC> <INPUTSTOPPEDSFC> 
<INPOTSTOPPEDREASONCODE> 

X'Cl 

X'05 

X'06 

X'04 

X'07 

<STOPINPUTRESPONSE> 

X'OO 



NOTES: 
1. 
2. 



5. 



See table 12-A for a definition of the format effectors. 

All data in the upline block marked with the DBC flag is considered to be 
transparent data. For downline data, the transparent flag takes precedence over the 
format effector selection. 

The actual text of (IVTCOMMANDTEXT) is the responsibility of PTIVTCMD; it is not the 
tip's responsibility. 

IVT bytes are ASCII characters, both upline an downline. The parity bit is ignored 
by the TIP for downline data. Upline, the parity bit must always be zero. 

A network block specifying autoinput in the DBC may contain only one logical line. 
It must be a MSG block. 
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TABLE 12-4. FORMAT EFFECTORS 



FE 


Preprint Action 


Postprint Action 


space 


single space 


no space 





double space 


no space 


- 


triple space 


no space 


+ 


position to start of current line 


no space 


* 


position to top of form or home cursor 


no space 


1 


home cursor and clear (page eject) 


no space 


r 


no space 


no space 


• 


no space 


single space 


/ 


no space 


position to start of current line 



written on the platen of a typewriter. 
The latter naturally includes platen (verti- 
cal) movement as well as head (horizontal) 
movement. 

If output follows input, the TIP processes format effectors 
to account for this repositioning. For example, a single 
space preprint format effector is treated as a null oper- 
ation when that format effects immediately follows an 
input operation. 

Following output of a logical line, the cursor is left where 
the data line terminated. Any subsequent output must 
therefore process the format effector as specified; that 
is, a single space preprint format effector causes the 
cursor to move to the first character position of the next 
line. Then the additional data can be transmitted. 

Some terminals cause special difficulties, since the cursor 
is not left at the end of the data line but is moved 
automatically to some other position. For example, on a 
Mode 4 display unit, the protocol requires an end of text 
symbol at the end of the logical line. The terminal 
displays this EOT symbol. However, this displaces the 
cursor to one character position past the last user 
character location. Following each output operation on 
such a terminal, the TIP can return the cursor to the first 
character position of the following line. Subsequent 
format effectors must account for the post output repo- 
sitioning. 

The TIP is required to display the data in the same way 
whether the network block was composed of a single 
logical line or of many logical lines. If the TIP repositions 
the cursor following each output, the TIP must also 
reposition the cursor at the end of each logical line. 

Whenever the TIP cannot perform the specific action 
directed by a format effector, the TIP must perform the 
same action as for a preprint single space. Also, the TIP 
must supply any idle characters that are needed to allow 
the terminal to perform a physical repositioning action. 
These idle characters, of course, follow the format 
effector. The rule for inserting idle characters is given 
below in the explanation of adding idle characters for line 
feeds and carriage returns. 



The TIP does not supply preprint or postprint cursor 
motion for downline IVT data which has no embedded 
format effectors. If the cursor cannot be left in the 
position following the last user character, the TIP returns 
the cursor to the first character of the next line, for 
every output physical line. 



IVT Character Processing 

An IVT data line can use any character in the standard 128 
character ASCII code set (see appendix A of the CCP 3 
Reference Manual). The TIP must be able to translate any 
of these characters to an equivalent terminal code 
character. 

There is one IVT code for a carriage return (CR) and 
another IVT code for a line feed (LF). When the TIP 
recognizes either of these codes it must be able to do two 
things: (1) issue a command to position the cursor to the 
proper location, and (2) issue characters that will allow 
the terminal sufficient time to position the cursor. The 
TIP provides this additional time by inserting idle char- 
acters following the carriage return or line feed. Then 
the TIP may resume outputting data characters. 

The idle character is defined by the terminal: it may be 
any non-displayed character that does not affect platen 
motion or paper movement, and does not have any other 
terminal function. The number of idle characters to be 
inserted is determined by the IVT commands. 

The sequences of CR LF or LF CR can be replaced by the 
new line function, if the terminal supports that function. 
If separate LF or CR functions are not supported by the 
terminal, the TIP can interpret the CR as a new line 
request and can discard all LF codes. 



Autoinput 

If the autoinput flag is set in the data block clarifier, the 
TIP must save the first 20 characters of the downline 
source data. The format effector and the unit separator 
must be discarded, as well as any characters following the 
twentieth. An autoinput block must be a message block, 
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and must contain a single logical line. When in autoinput 
mode, the TIP outputs the logical line, saves the first 
twenty characters, and waits for an input line. This input 
line is appended to the saved output characters, and the 
entire new line of data is returned to the application 
program in the host. It is possible to autoinput trans- 
parent data. 

Note that input data is reguired following this downline 
autoinput block. Note, also, that the entire output is 
delivered to the terminal, even if page wait logic would 
normally require fragmentation. 



Paging 

When the output data appears on a hard copy device such 
as a printer or a teletype, the TIP must provide paging for 
the data. The TIP counts input and output lines and 
inserts six new line reguests to provide page-to-page 
spacing. This spacing is intended to provide a fixed length 
for each page of a message. When a format effector 
selects a new page, a sufficient number of new line 
requests are inserted to position the page to the bottom of 
the page. Then the six new line requests are generated. 

If the printer supports a top-of-form or a page-eject 
function, that device feature should be used instead of 
new line requests. 

The TIP'S interpretation of format effectors must allow 
for platen positioning caused by paging logic. For 
example, a preprint format effector which occurs at the 
top-of-form can be ignored. Also, if a format effector 
causes multiple lines that would span a page boundary, the 
TIP treats the format effector as a top-of-form. 

The number of lines on a page is selectable by the IVT 
command %PL=nn. When the page length is nonzero and 
the output device is a hardcopy printer, paging is 
required. Page length on a display specifies the number of 
lines on the screen. 



Page Wait 

The IVT command %PG = Y selects the page-wait feature 
for display devices. This feature requires the TIP to 
construct and deliver one, and only one, full page of data 
to the terminal. In page-wait mode, the TIP must wait for 
input data after sending each full page of data. The TIP 
can construct a full page of data in either of two ways: 
(1) it can gather enough data to make a full page of data 
within the TIP, and send this data as a single transmission 
to the terminal, or (2) it can send multiple outputs to the 
terminal, so that the terminal constructs the page on the 
output device. 

A page is considered full whenever the TIP has 
transmitted PL - 1 lines. Note that the last line of the 
screen is reserved. This line is used by the terminal 
operator to enter the awaited input (page turn indication) 
so that more output can be sent later. A page is also 
considered to be full if the format effector requests a 
top-of-form or a page-eject. In such a case, the TIP must 
indicate that more data is to follow, even though the 
current page does not appear to be full. The TIP should 
send the message OVER so that it appears on the line 
following the last line of the output text. This alerts the 
operator that more user data will follow after the 
operator enters the page turn signal. If the page length is 
zero, only a top-of-form or page-eject format effector 
will cause a page-wait condition. 



The following things must be considered when calculating 
a full page: 

• IVT control codes CR and LF 
9 The page width 

The IVT command %PW = nn specifies the page width and 
indicates the physical boundary of a line. For hardcopy 
devices, the TIP must insert the proper new line codes to 
return the platen to the first character position of the 
next line. For display devices, page width specifies the 
column at which the terminal automatically inserts a new 
line; the TIP does not need to insert any codes. 

The TIP is not responsible for suppression of double 
spacing if the character following an automatic new line 
(or an inserted new line) is an IVT control code or the end 
of a logical line. 

The page width specification may cause line folding. The 
effect of line folding must be considered in calculating 
both paging and page wait. If a folded line would appear 
on the last line of a page (or both there and on subsequent 
lines), the line is fragmented. The second fragment of the 
line is saved; that fragment appears on the next page. 

For transparent output, page wait occurs following each 
message blocl<. 



Terminal Control Codes 

Downline data can contain ASCII control codes or escape 
sequences which cause actions to be performed by the 
terminal. The TIP writer has two choices for handling 
these: (1) the TIP may exclude the codes by substituting a 
blank for each such code, or (2) the TIP may transmit the 
codes unchanged. In the latter case, the TIP can elect to 
account for the cursor motion caused by the codes, or it 
can ignore the cursor motion and all its side effects. 
However, the TIP writer should note that such cursor 
motion can affect both paging and page wait. In any case, 
the TIP writer must assure that any such codes passed 
downline do not cause a terminal failure, result in error 
reports, or disconnect the user. 



Data Block Clarifier 

The data block clarifier (DBC) is used to indicate the 
format of the data. The format should remain consistant 
throughout a complete message. A message fragmented 
into a sequence of BLK blocks and a MSG block should all 
have the same value for the fragment or format effector 
flag. From message to message, however, the format may 
be changed as the application program desires. 



CMD Blocks 

Command (CMD) blocks are defined both upline and down- 
line. Only one of them is required by a user TIP; that is 
the downline CMD block containing an IVT command. 
Other CMD blocks are used by standard TIPS and by CDC 
application programs. These CMD blocks are a specially 
defined use and do not occur in any other circumstances. 
It is possible that a user TIP and a user application pro- 
gram could define such a special use of a CMD block. 

UPLINE IVT TRANSFORMS 

The upline IVT transform converts terminal data to ASCII 
data. Each sequence of characters is accumulated and 
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transferred to the host as a single message. The input 
sequence begins with the NPU detecting a character on 
the line, and the sequence ends with the NPU detecting a 
terminating character or sequence of characters. After 
the data is converted to IVT format, the data is checked 
for IVT functions before it is sent upline. 

The upline IVT transform discards any leading or trailing 
characters that are automatically supplied by the ter- 
minal, or required by the terminal's protocol. The termi- 
nating character is always sent by the terminal for its 
carriage return function. For block mode terminals, the 
terminating character can be any key which releases the 
data for transmission (such as an ETX). This terminating 
character or character sequence is always discarded. 



Backspace Processing 

If the terminal sends a backspace code in the data stream, 
the tip's input state programs usually process the char- 
acter. Backspace can be used only to correct characters 
in the same physical input line; that is, the user cannot 
backspace across a carriage return, line feed, or page- 
width boundary. 



Data Fragmenting 

The TIP can fragment upline data into multiple network 
blocks. All such fragments except the last are sent upline 
as BLK blocks. The last fragment is sent as a MSG block. 
The TIP can use any reasonable fragmentation rule, but 
the following factors should be considered: 

• Fragments should be at least 150 characters in 
length. A smaller fragment unduly raises the 
overhead cost of network block handling. 



only the IVT control code. The null line is treated as a 
prompt only if there is additional output available for 
transmission to the terminal. In this case, the prompt is 
discarded and the TIP resumes sending data to the ter- 
minal. If output is not available, a null message is sent to 
the host. If autoinput is being held, a null line satisfies 
the input, if it is not also a page turn prompt. 

Abort Line 

If output is interrupted by a break key or a full duplex 
input, the current output line is discarded, if the next 
input is an abort line. If any character except the abort 
output character is found on the input line, output is 
resumed starting from the beginning of the line. If a 
logical line consists of several physical lines, only the 
interrupted physical line is discarded. 



Cancel Line 

The last or only character of a line is checked to find if it 
is a cancel character. If it is, the message is discarded 
and the TIP sends a *DEL* message to the terminal. If an 
IVT command was being accumulated when cancelled, the 
command is discarded. If data was being accumulated and 
previous fragments have already been sent to the host, the 
TIP sends a null MSG block upline with the cancel flag set 
in the data block clarifier. 

If a cancel operation occurs rliring autoinput, the TIP 
discards any autoinput data it is saving. Note that the TIP 
continues to wait for input to complete the autoinput 
operation. Cancelling the autoinput data does not satisfy 
the requirement for input. 



IVT Command 



Fragmentation should be avoided unless charac- 
ters are being accumulated in the NPU memory at 
typing speeds. 

Fragments must not be released for upline trans- 
misaon unless the backspace cannot alter the data 
in the fragment. 

Fragmentation performed at the input state level 
can be reduced by concatenating blocks at the 
OPS level before passing the blocks upline to the 
host. 



Upline IVT Processing 

Before sending data to the host, the TIP must check the 
following IVT functions in the order listed (all checks are 
made after processing the data for a possible backspacing 
operation): 



Page turn prompt 

Abort input line 

Cancel input 

IVT command 

User break 1 or user break 2 

Autoinput 



If the first character of a message is the IVT control 
character, the TIP calls PTIVTCMD to process the 
command virfiich follows. The TIP accumulates the entire 
command before sending it to PTIVTCMD; that is, all 
fragments must be reassemebled, and none of the frag- 
ments are sent to the host. If the command exceeds 150 
characters in length, the remaining characters are dis- 
carded. 

If any of the IVT commands that are implemented require 
functional changes of the hardware (such as a com- 
munications line adapater command), the TIP must send 
all possible functions to the hardware, following each IVT 
command. The TIP does not parse or act on the IVT 
command. The TIP merely senses that a command oc- 
curred, and reinitializes all the hardware functions. 

PTIVTCMD determines the correct action to be taken for 
each IVT command, by reference to parameters in the 
field descriptor and field action tables. It is preferrable 
to accept all IVT commands, but to perform an action only 
for those which are appropriate for the type of terminal. 
The IVT commands are listed and described in the CCP 
System Programmer's Reference Manual. 



User Breaks 



Page Turn Prompt 

If the page wait feature is selected, the TIP must check 
for a page turn prompt. The prompt has two forms: (1) a 
message containing no data, or (2) a message containing 



The user break code must be the first and only character 
of a message. If a user break is found in a message, the 
data is discarded and the TIP generates a BRK block 
which is sent to the host. All internally held downline 
data (including autoinput data) is discarded. 
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Auto input 

If the TIP is holding autoinput when input arrives, the 
input data is chained to the autoinput data. The result is 
sent to the host as one input message. After autoinput 
has been sent to the host, the next output can be sent to 
the terminal. Autoinput data can be cancelled by the 
cancel character; however, the TIP must still wait for 
upline data before permitting the next output transmission. 

Transparent Input Data 

An IVT command (either from the terminal or sent down- 
line from the host) can cause the TIP to process input data 
in transparent mode. The command applies to the next 



input message. Successful receipt of input data cancels 
transparent mode, so a new command is required for each 
line that is to be processed as transparent data. The TIP 
must inspect the BSXPARENT field of the TCB prior to 
each input operation to determine the processing mode. 
After sending the input line to the host, the TIP must set 
the BSXPARENT flag to FALSE. During transparent 
mode processing, the TIP checks for the pige turn 
prompt. Autoinput is permissible in transparent mode. 
Only a null line input with data available for output is 
considered to be a valid page turn prompt in tranparent 
mode; the IVT control code is not considered a page 
prompt. 
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CCP provides a text processor for processing the various 
character translations that are necessary when network 
data is converted to terminal data. The network data is in 
interactive virtual terminal (IVT) format, in batch virtual 
terminal (BVT) format, or is transparent data. Terminal 
data is normally in a different format. The usual principal 
differences are as follows: 

• A different code set than the network's 

• A terminal transmission buffer size different than 
the network block sizes 

• Terminal operating characteristics that are not 
identical to IVT or BVT 

Text processing is usually required downline. A TIP can be 
written to perform upline text processing also. 

TEXT PROCESSING STATE 
PROGRAMS 

The TIP is responsible for making the translations, using a 
specialized language for character processing. This lan- 
guage contains most of the same instructions that are 
available to the input state programs for upline character 
processing . The instructions are described in detail in the 
State Programming Language Reference Manual. A few 
state programming instructions are available only for text 
processing, and cannot be used by the input state pro- 
grams. All instructions are written into firmware level 
text processing state programs, and are interpreted by the 
text processor, when the TIP calls that firmware module 
via PTTPINF. 

When the TIP is ready to translate a source message, the 
TIP sets up a control table called the Text Processing 
Control Block (TPCB), which is an overlay of the Mux LCB 
(NCLCB). This TPCB contains the pointers to the source 
data buffers, the instructions to be interpreted (that is, 
the address of a pointer table to the TIP's firmware level 
text processing state programs), and other TIP-defined 
fields. The TPCB was discussed in section 6, principal 
data structures. When the table is ready, the TIP makes a 
direct call to PTTPINF. This transfers control to the text 
processor, which controls the TIP's own text processing 
state programs. 

The principal characteristics of executing PTTPINF are: 



Example of a call : 

WITH BITCB .BSTCB, (TPCBptr ) DO 



Procedure name: 
Input parameter: 

Return parameter: 

Calling Sequence: 



PTTPINF 

(TPCBptr) = address of the 
TPCB 

(errcode) = text processing 
failure indicator 

PTTPINF (TPCBPTR); 



BEGIN 

NCaaa : 



value; 



NCzzz ; = value; 
PTTPINF(TPCBptr); 



SPECIFY TPCB 
ADDRESS 



SET UP ALL 
THE NECESSARY 
TPCB FIELDS 



END; 



The text processor supplies destination buffers to receive 
the translated characters, as necessary. The text pro- 
cessing state programs handle each source character and 
determine its disposition. In general, the translated char- 
acters will be sequentially placed in the destination buf- 
fers. On return to the TIP, the TPCB holds pointers to the 
source data buffers and to the destination buffers. 

The text processor is normally called for downline data. 
In all cases, the text processor is called only from the 
OPS-level TIP. Text processing translations are per- 
formed at a lower priority level than input state program 
processing, so input character translations can interrupt 
text processing translations. However, no other OPS-level 
program can gain control of the NPU while a text pro- 
cessing operation is in progress. Therefore, there is no 
need for reentrant coding in the TIP's firmware-level text 
processing state programs. 

DOWNLINE TEXT PROCESSING FOR 
LOW AND MEDIUM-SPEED LINES 

For TIPs which operate on lines with baud rates at or 
below 9600, text processing is done on demand; that is, 
one block of data is removed from the TIP's output queue 
and a sufficient amount of that data is translated and 
given to the multiplex subsystem for transmission. On 
completion of the transmission, the TIP translates more 
output data and passes it to the multiplex susbsystem. 
This process continues until there is no more data to be 
transmitted. In demand mode, there is never any output 
on the line during a text processing operation. 

DOWNLINE TEXT PROCESSING FOR 
HIGH-SPEED LINES 

For a TIP to efficiently utilize a line that operates at 
higher baud rates, text processing and output transmission 
are performed simultaneously. To accomplish this, the 
TIP must remove enough data from the output queue to 
create two transmission blocks. As soon as this amount of 
data is text processed, the first transmission block is 
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passed to the multiplex subsystem for sending. As soon as 
the first block is successfully sent, the TIP passes the 
second block to the multiplex subsystem. Then the TIP 
immediately gets another block from its output queue and 
starts text processing that block into another transmission 
block. 

Except for starting a message, the TIP must not remove 
more than one block from its output queue without 
sending an acknowledgment to the host (the TIP has the 
choice of delaying the acknowledgement for fragmented 
blocks). In the special case where the first two trans- 
mission blocks must be translated before either of them is 
sent, the TIP may remove more than one network block 
from its output queue. The BIP routine PTBACK can be 
called to acknowledge to the host that the first block was 
unqueued. This allows the second block to be unqueued. 

If PTBACK is used in this manner the postoutput POI 
(PBPOPOI) must be used only for accounting purposes, and 
not for control. To do this, the TIP sets the internal block 
flag (BFINTBLK) to inhibit PBPROPOI from transmitting 
another BACK block upline. If the TIP is to accomodate 
the usual application program delivery assurance require- 



ments, the TIP must itself preserve the data acknowl- 
edged but not sent to the terminal, even though a BRK or 
STP block is sent upline. The application program will not 
resend those blocks which were acknowledged by the TIP. 



UPLINE TEXT PROCESSING 

Text processing may also be performed on upline data. In 
most cases, the TIP's input state programs will have 
already translated the data during input processing, as the 
characters were being demultiplexed from the circular 
input buffer. If a complete data translation cannot be 
performed at this time, the TIP must supply upline text 
processing programs to finish the text translation. The 
input data buffers supplied by the multiplex subsystem 
become the source buffers for this upline text processing 
operation. The call to PTTPINF is the same as for down- 
line text processing. When text procesing is complete, the 
TIP calls the postinput POI to send the blocks upline. 



Note that two-pass text 
effect on NPU utilization, 
passible. 



processing has a considerable 
and should be avoided if at all 
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PASCAL GLOBAL INITIALIZATION 



14 



There are two ways to initialize PASCAL variables for the 
TIP: by using VALUE statements, or by using executable 
initialization code. Use of VALUE statements is limited 
by restrictions on the syntax. It also causes hard-coded 
numeric fields to be used, instead of the symbolic names 
which are more appropriate for PASCAL. Initialization by 
executable code requires that the TIP maintain code that 
is used only during system initialization. 

To resolve both these problems, an editing capability was 
created for use during the build process. This editing 
process is called MPEDIT. MPEDIT allows value ini- 
tialization using symbolic names, and it provides value 
initializations of addresses which are known only after a 
system is linked and absolutized. 



MPEDIT DIRECTIVES 

MPEDIT directives are used to initialize variables and 
fields for PASCAL globals. If the user is not thoroughly 
familiar with MPEDIT directives, he is urged to review 
the edit phase section of the CYBER Cross System Link 
Editor and Library Maintenance Reference Manual. The 
insertion of MPEDIT decks is shown in section 4 of this 
manual. 

The codes described below may be necessary for 
modifying a TIP or for writing a new TIP. The MPEDIT 
program structure is shown in figure 14-1. A / preceding 
a symbolic name indicates a symbol defined only to 
MPEDIT. Symbols not preceded by a / are defined for 
PASCAL or assembly language or MPLINK. 



• Cancel character 

• IVT control character 

• User break 1 character 

• User break 2 character 

• Transparent delimiter character 

• Backspace character 

• Character length in bits 

Constants are defined by: 

/CONSTNAME = nr; 

where CONSTNAME is the TIP's local mnemonic, nr is 
the value assigned to that mnemonic. ; ends the constant 
definition. 

Constant definitions are contained in the user suoolied 
COMDECK ZCNtip. 



MPEDIT VARIABLES 

MPEDIT variables define symbolic names which are 
defined only to MPEDIT, and are used for numeric 
calculations. Probably the user neither needs to add to, 
nor change, any of the standard CCP edit phase variables. 
If it becomes necessary to add a variable, the format of 
the variable declaration is: 

/VARNAME; 

where VARNAME is the variable name. ; ends the 
variable declaration. 



PROGRAM STRUCTURE 



CONST 

Constant definitions 



VAR 



Variable declarations 



ARRAY 

Array declarations 



BEGIN 

Assignment section 

END 



CONST 

VAR 

ARRAY 

BEGIN 

END 

FOR 

TO 

DO 

OF 

CHAR 



Keyword s 



Figure 14-1. MPEDIT Program Structure 



MPEDIT CONSTANTS 

Constant definitions are added by the TIP writer to create 
symbolic names which are subsequently used by MPEDIT 
statements during value initialization. The constants are 
usually default values for: 



Variables /I, /J, /K, and /L are available for TIP use 
without special definition. User-defined variables are 
contained in the user-supplied COMDECK VARtip. 

MPEDIT ARRAYS 

To initialize values in arrays, the TIP writer must define 
for MPEDIT both an index range and a length of element 
(these parameters are not placed in the symbol table by 
PASCAL). Array declarations have the format: 

ARRAYNAME [RANGE] OF SIZE; 

where ARRAYNAME is the symbolic name of the array 
declared in the PASCAL global variable declaration 
section. ARRAYNAME may be any entry point name 
which allows initialization of arrays in assembly language 
programs. Range is a subrange declaration of the form: 

M..N 

where M and N are numeric constants or symbols. SIZE is 
the number of words in an array entry. ; ends the variable 
declaration. 

Array declarations are contained in the user COMDECK 
ZARtip. 
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ASSIGNMENT SECTION 

Each TIP has a section of code in the MPEDIT assignment 
section. The assignment statements most likely to be 
required are as follows: 



LCB descriptor table 

TCB descriptor table 

Worklist control block 

TIP type table 

Terminal characteristics table 

TCB/LCB action tables 

State program address linkage 



Each of these is discussed separately later. 



WORKLIST CONTROL BLOCK 

Each TIP defines a worklist control block. Format of the 
block's initialization code is as follows: 



BYWLCB [BOUSERn] . BYPRADDR 
BYWLCB [BOUSERn] . BYPAGE 



= /ENTRY 
(procname); 

= /PGNUM 
(procname); 



BYWLCB [BOUSERn] . BYWLINDEX 
BYWLCB [BOUSERn] . BYMAXCNT 
BYWLCB [BOUSERn] . BYINC 
BYWLCB [BOUSERn] . BYWLREQ 



= BOUSERn; 

= 1 

= 3 

= /TRUE 



where BOUSERn is the index of the worklist in the OPS 
MONITOR TABLE (BYWLCB), with n ranging from 1 to 
A. Procname is the procedure name containing the 
OPS-level entry point of the TIP. 



TIP TYPE TABLES 

Each TIP requires a TIP type table. Almost every field of 
this table must be initialized. The typical definition for 
an entry is: 



BYTIPTYPT NOUTTn] . field 



value; 



where NOUTTn is the TIP type definition index. Standard 
TIPs use n values of 1 through 4. The TIP writer must 
define a new value for n for his TIP. Field is one of the 
fields as defined in the TIP type table. The fields usually 
defined are shown in table 14-1. Value may be locally 
defined, or it may be a global symbol. 



TABLE 14-1. TIP-TYPE TABLE DEFINITIONS 



Field 


Range 


Comments 


BJOBT 


TRUE or FALSE 


Output buffer terminated worklist is to be generated 
(not usually needed for controlled protocols) 


BJBZL 


TRUE or FALSE 


Reset timer flag when output buffer termination occurs. 
Controlled protocols reset timer after a successful 
output in order to time the terminal's response. 


bjiVtsize 


BSLFIDLES to 
BSPGWIDTH + 1 




BJTCBSIZE 


/BO 832 


TCB for a TIP always requires a 32 word buffer 


BJOTYPE 


/BOQNEXTSEG 




BJLISTIX 


BOUSERn 


Index to the worklist control block 


BJDFTC 


NODSERl - N0USER5 
for user terminal 
classes 


Default terminal class when line is enabled 


BJJFDC 


VATnFDT for 
n = 1 to 4 


Address of TIP's TCB descriptor table 


BJFDT 


VALnFDT for 
n = 1 to 4 


Address of TIP's LCB descriptor table 


BJJAT 


VATnAT for 
n = 1 to 4 


Address of TIP's TCB action table 


BJAT 


VALnAT for 
n = 1 to 4 


Address of TIP's LCB action table 


BJTIFMUX2 


/PGNUMCprocname ) 


Page number of the Mux-2 level entry to the TIP 


BJTEMUX2 


/ENTRY(procname) 


Entry point for the Mux-2 level entry to the TIP. 
Defined only for those TIPs that have a routine 
exclusively for handling Mux-2 level inputs. 


BJTCBPINIT 


/ PGNUM ( p roc name ) 


Page number for the TIP's TCB initialization routine 
(direct call from service module) 


BJTCBEIIIIT 


/ENTRY(procnaine) 


Entry point for the TIP's TCB initialization routine 
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See figure 14-2 for sample MPEDIT 
initialize TIP type table. 



statements to 



TIP-tyPE TABLE FOR 


USER TIP 1 






BJTIPTYPT NOUTTl 


.BJOBT 


,_ 


/TRUE; 


BJTIPTYPT NOUTTl 


.BJBZL 


l^ 


/FALSE; 


BJTIPTYPT NOUTTl 


.BJTCBSIZE 


: = 


/BJS32; 


BJTIPTYPT NOUTTl 


.BJQTYPE 


= 


/BJQNEXTSEQ; 


BJTIPTYPT NOUTTl 


-BJLISTIX 


= 


/BOUWLl ; 


BJTIPTYPT NOUTTl 


.BJDFTC 


= 


/NOUTCl; 


BJTIPTYPT NOUTTl 


.BJJFDT 




/UATIFDT; 


BJTIPTYPT NOUTTl 


.BJFDT 




UALIFDT; 


BJTIPTYPT NOUTTl 


•BJJAT 


= 


UATIAT; 


BJTIPTYPT NOUTTl 


.BJAT 


= 


UALIAT; 


BJTIPTYPT NOUTTl 


.BJTEMUX2 


— 


/ENTRY (procname); 


BJTIPTYPT NOUTTl 


.BJTPMUX2 


= 


/PGNUM (procname); 


BJTIPTYPT NOUTTl 


.BJIVTSIZE 


= 


BSLFIDLES - 
BSPGWIDTH + 1; 


BJTIPTYPT NOUTTl 


.BJTCBPINIT : 


= 


/ENTRY (procname); 


BJTIPTYPT NOUTTl 


.BJTCBPINIT : 


= 


/PGNUM (procname); 



Figure 14-2. MPEDIT Statements to Initialize TIP Type 
Table (Sample) 



TERMINAL CLASS TABLE 

A terminal class table must be defined for each of the 
TIP'S terminal classes. Two catagories of tables are 
usually defined: one for the base fields and one for the 
IVT overlay fields. The content of these tables may vary 
widely from TIP to TIP. For the same TIP, however, the 
same fields are set for each terminal class. Format of a 
table entry initialization is: 



NJTECT [NoUTT^ . field : = value; 



where NOUTTn is the terminal class with n ranging from 1 
through 4. Field is the NJTECT field mnemonic. Table 
14-2 shows the fields defined for TIPs. Value is a 
symbolic or absolute value. 

See figure 14-3 for sample MPEDIT statement to initialize 
terminal class table. 



TERMINAL CHARACTERISTICS (BASE FIELDS) FOR TERM CLASS NOUTCl 1 


NJTECT NOUTCl 


.NJISPTA := 


UAISPTR; INPUT STATE ADDR 


NJTECT NOUTCl 


.NJTIPTY := 


NOUTTl; 


NJTECT NOUTCl 


.NJPARITY := 


B7EVPAR; 


NJTECT NOUTCl 


.NJCHLEN : = 


/CLSEVEN; 


IVT TERM CHARACTERISTICS FOR 


TERM CLASS NOUTCl 


NJTECT NOUTCl 


.NJPGWAIT 


:= /FALSE; 


NJTECT NOUTCl 


.NJPGWIDTH 


.= 72; 


NJTECT NOUTCl 


.NJPG LENGTH 


:= 0; 


NJTECT NOUTCl 


.NJCANCHAR 


= /I31CANCHR; 


NJTECT NOUTCl 


.NJCNTRLCHAR 


= /I31CNTRLCHR; 


NJTECT NODTCl 


.NJUSRl 


= /I31UB1; 


NJTECT NOUTCl 


.NJUSR2 


= /I31UB2; 


NJTECT NOUTCl 


.NJXCHAR 


= /I31XCHAR; 


NJTECT NOUTCl 


.NJBSCHAR 


= /I31BSCHAR; 


NJTECT NOUTCl 


.NJABTLINE 


= /I31ABTLIME; 


NJTECT NOUTCl 


.NJXPARENT 


= /FALSE; 


NJTECT NOUTCl 


.NJXTO ! 


= /FALSE; 


NJTECT NOUTCl 


.NJXCNT 


= 2043; 


NJTECT NOUTCl 


.NJCRCALC : 


= /TRUE; 


NJTECT NOUTCl 


.NJCR IDLES : 


= 2; 



Figure 14-3. MPEDIT Statement to Initialize Terminal Class 
Table (Sample) 



FIELD DESCRIPTOR TABLE DEFINITION 

Normally, the TIP writer is not required to add new field 
name/field value (fn/fv) pairs to line or terminal 
configuration. These changes require host code changes. 
Only those fn/fv values that are defined for existing TIPs 
are described here. The TIP-defined line field descriptor 
table defines the line speed option. The TCB field 
descriptor is nil. The example shown in figure 14-4 is for 
USER TIP 1 and is contained in user supplied COMDECK 
ZEXtip. 



********************************************* 

* * 

* USER TIP 1 TCB FIELD DESCRIPTOR TABLE * 

* * 
**************************************^jtj^^^^j^ 



UATIFDT .ODNUMENT := 0; 



NUMBER OF ENTRIES 



***************&*******4**************^^j^4.^^j^ 

* * 

* USER TIP 1 LCB FIELD DESCRIPTOR TABLE * 

* * 
*****************************************^^^^ 



UALIFDT .DDNUMENT := 1; 



NUMBER OF ENTRY 



/BZLNSPD 
UALIFDT 1 
UALIFDT 1 
UALIFDT 1 



.raiFSTRT 
.DDFUfTH 
.MJFDISP 



= 21; 

= /START(BZmSPD); 
= /LENGTH (BZLNSPD); 
= BZLNSPD; 



Figure 14-4. TCB and LCB Field Description Table 
Initialization (Sample) 



ACTION TABLE INITIALIZATION 

The following checks are manditory during a terminal 
configuration operation: 

■ /BSTCLASS - terminal class. Upper and lower 
bounds must be checked (D2VU and D2VL). If this 
is a reconfigure terminal service message, a 
variant TCB (D2TCBDFLT) should be established. 

■ /BSCN - change CN. The connection number must 
be processed (D2ACN). 

■ /SN - data path between host and terminal. The 
directory change must be processed (D2LLCB). 

• /DN - new path to terminal for data from host. 
The directory change must be processed 
(D2LLCB). 

• /BSNBL - network block limit. 

■ /BSIPRI - data priority. 

■ Internal (0) - three internal actions are possible. 
The new TIP must determine which of these 
internal actions is required. The first two or 
three action table entries are reserved for these 
internal actions (as was described earlier in the 
direct SVM to TIP call in the service module 
interface). Normally, D2TCBCHN, D2TCBINrT, 
and D2INIT, are used in that order. The remaining 
actions are descretionary; these usually check the 
upper and/or lower bound of the field to be 
initialized. The bound must be supplied in the 
fourth word of the entry (.DFPARAM : = x ). 
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TABLE 14-2. TERMINAL CHARACTERISTICS TABLE DEFINITIONS 



Field 



NJXSPTA 



NJCXLTA 



NJCNTl 



NJSYNC 



NJCRCP 



NJIBFCD 



NJBLKL 



NJTIPTY 



NJPARITY 



NJCHLEN 



NJPARTYPE 



NJPGWAIT 



NJXPARENT 



Value /Comments 



address of input states pointer table 



address of code translate table 



initial value for counter 1 (0-255) 



SYNC character for protocol 



CRC polynomial index (see SPRM) 



character displacement for first character to be stored in first buffer 



reset value for count 2 (0-16383) 



TIPTYPE 



parity option 

B70DDPR : odd parity 
B7N0PAR : no parity 
B7EVPAR ; even parity 



character length (see CLA Reference Manual for values) - normal 1 for 8-bit characters 



parity type 

B 7 ZERO : zero parity 

B70DD : odd parity 

B7EVEN : even parity 

B7N0NE : no parity 



page wait option (/TRUE, /FALSE) 



Transparent input 



IVT Parameters 



The following fields must start on a word boundary: 

PAGE WIDTH 

PAGE LENGTH 

CANCEL INPUT LINE CHAR 

CONTROL CHARACTER 

USER BREAK ONE 

USER BREAK TWO 

TIMEOUT IS EXPECTED DELIMITER 

XPT CHAR IS A DELIMITER 

TRANSPARENT CHARACTER COUNT 

CR IDLE CNT TO BE CALCULATED 

LF IDLE CNT TO BE CALCULATED 

ECHOPLEX MODE 

INPUT DEVICE (F=KB, T=PT) 

OUTPUT DEVICE (PRT, DISPLAY, PT) 

APL (0=N0, 1=YES, 2=SPECIAL) 

TRANSPARENT DELIMITER CHAR 

BACKSPACE CHARACTER 

ABORT OUTPUT LINE CHARACTER 

COUNT OF IDLES AFTER CR 

COUNT OF IDLES AFTER LF 



the device type is a console. The permissabla values for these parameters 
are defined by the IVT specifications (see the CCP System Programmer's 
Reference Manual). 



NJPGWIDTH : 


B08BITS; 


NJPGLENGTH 


B08BITS; 


NJCANCHAR : 


CHAR; 


NJCNTRLCHAR 


CHAR; 


NJUSRl 


CHAR; 


NJUSR2 


CHAR; 


NJXTO 


BOOLEAN; 


NJXCHRON 




NJXCNT 


B012B1TS; 


NJCRCALC 


BOOLEAN; 


NJLFCALC 


BOOLEAN; 


NJECHOPLX 


BOOLEAN; 


NJINDEV 


BOOLEAN; 


NJOUTDEV 


B02BITS; 


NJAPL 


B02BITS; 


NJXCHAR 


: CHAR; 


NJ ESCHAR 


CHAR; 


NJABTLINE 


CHAR; 


NJCPIDLES 


B08BITS; 


NJLFIDLES 


: B08BITS); 


Note: The IV 


r parameters 
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Figure 14-5 shows an example of an action table 
initialization. All the remaining values in the example 
may be checked; but there is no requirement to check 
them. These fields permit optional terminal specification; 
in the terminal definition statements of NDL, or by IVT 



commands from a terminal or from an application 
program. Omission indicates that processing is skipped. 
The example shows a complete set, whether it is needed 
by the TIP or not. 













* 






* 




* USER TIP 1 TCB 


ACTION TABLE * 




*********************************** 




/L : = 


1; 








HAT 1 AT /L 


.DFFN 


:= 0; INTERNAL 


ACTION 


UATIAT 


/L 


.DFRKEY 


:= D2SKP; 




UATIAT 


/L 


.DFCKEY 


:= D2TCBCHN; 




UATIAT 


/L 


.DFPARAM 


:= 0; 


/L := /L + 1 


UATIAT /L 


.D^N 


:= 0; 




UATIAT 


/L 


•DFRKEY 


:= DESKP; 




UATIAT 


/L 


.DFCKEY 


:= DZTCBINIT; 




UATIAT 


/L 


.DFPARAM 


:= 0; 


/L := /L + 1 


UATIAT 


/L 


.DFFN 


:= 0; INTERNAL 


ACTION 


UATIAT 


/L 


.DFRKEY 


:= D2INIT; 




UATIAT 


/L 


•DFCKEY 


:= D2INIT; 




UATIAT 


/L 


.DFPARAM 


:= 0; 


/L := /L + 1 


UATIAT 


/L 


•DFFN 


:= /BSTCLASS; 




UATIAT 


/L 


•DFRKEY 


:= D2VUL; 




UATIAT 


/L 


.DFCKEY 


:= D2VUL; 




UATIAT 


/L 


.DFPARAM 


:= $801 


/L := /L + 1 


UATIAT 


/L 


.DFFN 


:= /BSTCLASS; 




UATIAT 


/L 


.DFRKEY 


:= D2VM; 




UATIAT 


/L 


.DFCKEY 


:= D2NA; 




UATIAT 


/L 


.DFPARAM 


:= $204 


/L := /L + 1 


UATIAT 


/L 


.DFFN 


:= /BSTCLASS; 




UATIAT /L 


.DFRKEY 


:= D2TCBDFLT; 




UATIAT 


/L 


.DFCKEY 


:= D2NA; 




UATIAT 


/L 


.DFPARAM 


:= 0: 


/L := /L + 1 


UATIAT 


/L 


•DFFN 


:= /BSOWNER; 




UATIAT 


/L 


•DFRKEY 


:= D2VL; 




UATIAT 


/L 


•DFCKEY 


!= D2VL5 




UATIAT 


/L 


•DFPARAM 


:= 0: 


/L := /L + 1 


UATIAT 


/L 


•DFFN 


:= /BSCN; 




UATIAT 


/L 


•DFRKEY 


:= D2ACN; 




UATIAT 


/L 


•DFCKEY 


:= D2ACN; 




UATIAT 


/L 


•DFPARAM 


:= 0: 


/L := /L + 1 


UATIAT /L 


•DFFN 


:= /DN; 




UATIAT /L 


•DFRKEY 


:= D2ADN; 




UATIAT 


/L 


•DFCKEY 


:= D2SKP; 




UATIAT 


/L 


•DFPARAM 


:= 0: 


/L := /L + 1 


UATIAT 


/L 


• DFFN 


:= /SN; 




UATUT 


/L 


.DFRKEY 


:= D7T,T,CB; 




UATIAT 


/L 


•DFCKEY 


:= D2LLCB; 




UATIAT 


/L 


•DFPARAM 


:- 0: 


/L := /L + 1 


UATIAT 


/L 


•DFFN 


:= /BSNBL; 




UATIAT 


/L 


•DFRKEY 


:= D2VU; 




UATIAT 


/L 


•DFCKEY 


:= D2VU; 




UATIAT /L 


•DFPARAM 


:= 7: 


/L := /L + 1 



Figure 14-5^ MPEDIT Initialization of USER TIP 1 TCB Action Table 
(Sample; 1 of 3) 
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UATIAT /L 
UATIAT /L 
UATIAT /L 
UATIAT /L 


.DFFN 
.DFRKEY 
.DFCKEY 
.DFPARAM 


= /BSIPRI; 
= D2Vn; 
= D2VU; 
= 3; 


UATIAT /L 
UATIAT /L 
UATIAT /L 
UATIAT /L 


.DFFN 
.DFRKEY 
.DFCKEY 
.DFPARAM 


= /BSIPRI; 
= D2VL; 
= D2VL; 
= 1: 


UATIAT /L 
UATIAT /L 
UATIAT /L 
UATIAT /L 


.DFFN : 
.DFRKEY : 
.DFCKEY : 
.DFPARAM : 


= /BSCANCHAR; 
= D2Vn; 
= D2VU; 
= 127; 


UATIAT /L 
UATIAT /L 
UATIAT /L 
UATIAT /L 


.DFFN : 
.DFRKEY : 
.DFCKEY : 
.DFPARAM : 


= /BSBSCHAR; 
= D2VU; 
= D2Vn; 
= 127; 


UATIAT /L 
UATIAT /L 
UATIAT /L 
UATIAT /L 


.DFFN : 
.DFRKEY : 
.DFCKEY : 
•DFPARAM : 


= /BSCNTRLCHAR; 
= D2VH; 
= D2VU; 
= 127; 


UATIAT /L 
UATIAT /L 
UATIAT ft 
UATIAT /L 


• DFFN : 
.DFRKEY : 
.DFCKEY : 
.DFPARAM : 


= /BSCRIDLES; 
= D2VU; 
= D2VU; 
= 99; 


UATIAT /L 
UATIAT It 
UATIAT /L 
UATIAT /L 


.DFFN : 
.DFRKEY : 
.DFCKEY : 
.DFPARAM ; 


= /BSLFIDLES; 
= D2VU; 
= D2VU; 
= 99; 


UATIAT /L 
UATIAT /L 
UATIAT /L 
UATIAT /L 


.DFFN : 
.DFRKEY : 
.DFCKEY : 
.DFPARAM : 


= /BSCRCALC; 
= D2VU; 
= D2VU; 

= 1; 


UATIAT It 
UATIAT It 
UATIAT It 
UATIAT /L 


.DFFN : 
.DFRKEY • 
.DFCKEY : 
.DFPARAM : 


= /BSCRCALC; 
= D2CRIDLE; 
= D2CRIDLE; 
= 0; 


UATIAT It 
UATIAT It 
UATIAT It 
UATIAT It 


.DFFN : 
.DFRKEY ! 
.DFCKEY ! 
.DFPARAM 


= /BSLFCALC; 
= D2VU; 
= D2VU; 
= 15 


UATIAT It 
UATIAT It 
UATIAT It 
UATIAT It 


.DFFN : 
.DFRKEY 
•DFCKEY : 
.DFPARAM 


= /BSLFCALC; 
= D2LFIDLE; 
= D2LFIDLE; 
= 0; 


UATIAT It 
UATIAT It 
UATIAT It 
UATIAT It 


.DFFN ; 
.DFRKEY • 
.DFCKEY : 
.DFPARAM 


= /BSAPL; 
= D2VU; 
= D2VU; 
= 2; 


UATIAT It 
UATIAT It 
UATIAT It 
UATIAT /L 


•DFFH : 
.DFRKEY 
.DFCKEY : 
.DFPARAM 


= /BSAPL; 
= D2APL; 
= D2APL; 
= 0; 


UATIAT It 
UATIAT /L 
UATIAT /L 
UATIAT It 


.DFFN : 
.DFRKEY 
.DFCKEY • 
•DFPARAM 


= /BSXPARENT; 
= D2VU; 
= D2VU; 

= 1; 



/L := /L + 1 



It := /L + 1 



It := /L + 1 



It := /L + 1 



It := /L + 1 



It := /L + 1 



It := It + 1 



It := /L + 1 



It := /L + 1 



/L := /L + 1 



It := /L + 1 



It := /L + 1 



It := /L + 1 



It := /L + 1 



Figure 14-5. MPEDIT Initialization of USER TIP 1 TCB Action Table 
(Sample; 2 of 3) 
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UATIAT /L 


.DFFN 


: = 


/BSKCHM; 




HATIAT /L 


.DFRKEY 


: = 


D2VU; 




HATIAT /L 


.DFCKEY 


: = 


D2VU; 




UATIAT /L 


.DFPARAM 


: = 


15; 


/L := /L + 1 


HATIAT /L 


.DFFN 


: = 


/BSXTO; 




UATIAT /L 


.DFRKEY 


! = 


D2VH; 




UATIAT /L 


.DFCKEY 


: = 


D2VU; 




UATIAT /L 


.DFPARAM 


: = 


1; 


/L := /L + 1 


UATIAT /L 


.DFFN 


.= 


/BSINDEV; 




HATIAT /L 


.DFRKEY 


: = 


D2VH; 




UATIAT /L 


.DFCKEY 


: = 


D2vn; 




UATIAT /L 


.DFPARAM 


: = 


1; 


/L := /L + 1 


UATIAT /L 


•DFFN 


: = 


/BSOUTDEV; 




UATIAT /L 


.DFRKEY 


: = 


D2VH; 




HATIAT /L 


.DFCKEY 


: = 


D2Vn; 




UATIAT /L 


.DFPARAM 


: = 


2; 


/L := /L + 1 


UATIAT /L 


.DFFN 


: = 


/BSECHOPLX; 




UATIAT /L 


.DFRKEY 


: = 


D2VH; 




UATIAT /L 


.DFCKEY 


: = 


D2VH; 




UATIAT /L 


.DFPARAM 


: = 


1; 


/L := /L + 1 


UATIAT /L 


.DFFN 


: = 


/BSPGWAIT; 




UATIAT /L 


•DFRKEY 


: = 


D2VH; 




UATIAT /L 


.DFCKEY 


: = 


D2VH; 




UATIAT /L 


•DFPARAM 


: = 


1; 


/L := /L + 1 


UATIAT /L 


.DFFN 


.= 


/BSPARITY; 




UATIAT /L 


.DFRKEY 


: = 


D2VH; 




HATIAT /L 


•DFCKEY 


: = 


D2VH; 




UATIAT /L 


•DFPARAM 


.= 


3; 


/L := /L + 1 


UATIAT /L 


•DFFN 


.= 


/BSPARITY; 




HATIAT /L 


•DFRKEY 


: = 


D2PARITY; 




HATIAT /L 


•DFCKEY 


: = 


D2PARITY; 




HATIAT /L 


•DFPARAM 


: = 


0; 


/L := /L + 1 


HATIAT /L 


•DFFN 


: = 


/BSABTLINE; 




HATIAT /L 


.DFRraY 


: = 


D2VU; 




UATIAT /L 


.DFCKEY 


: = 


D2VH; 




HATIAT /L 


.DFPARAM 


:= 


127; 


/L := /L + 1 


UATIAT /L 


•DFFN 


.,= 


/BSUSRl; 




HATIAT /L 


•DFRKEY 


: = 


D2VU; 




UATIAT /L 


•DFCKEY 


: = 


D2VU; 




UATIAT /L 


•DFPARAM 


; = 


127; 


/L := /L + 1 


UATIAT /L 


•DFFN 


; = 


/BSHSR2; 




UATIAT /L 


•DFRKEY 


: = 


D2VU; 




UATIAT /L 


.DFCKEY 


: = 


D2VH; 




UATIAT /L 


.DFPARAM 


:= 


127; 


/L := /L + 1 


UATIAT /L 


.DFFN 


.= 


/BSCOJE; 




UATIAT /L 


.DFRKEY 


: = 


D2VL; 




UATIAT /L 


•DFCKEY 


: = 


D2VL; 




UATIAT /L 


•DFPARAM 


: = 


4; 


/L := /L + 1 


UATIAT /L 


•DFFN 


.= 


/BSC(»)E; 




UATIAT /L 


• DFRKEY 


Jas 


D2VH; 




UATIAT /L 


.DFCKEY 


: = 


D2VH; 




UATIAT /L 


.DFPARAM 


: = 


5; 


/L := /L + 1 


UATIAT /L 


•DFFN 


: = 


/BSXCHRON; 




UATIAT /L 


•DFRKEY 


: = 


D2VU; 




HATIAT /L 


.DFCKEY 


: = 


D2VH; 




UATIAT /L 


•DFPARAM 


• = 


1; 


/L := /L + 1 


UATIAT /L 


•OFEND 


: = 


$7FFK: END OF TABLE 1 



Figure 14-5. MPEDIT Initialization of USER TIP 1 TCB Action Table 
(Sample; 3 of 3) 
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Table 14-3 defines all the terminal configuration field 
numbers and the associated mnemonic names. In 
initialization statements, a / precedes the field name, 
since these MPEDIT variables are defined for the TIP 
writer. The set of terminal initialization statements are 
placed in the user supplied COMDECK ZEXtip. 



An optional check can be made for line speed, if the line 
is asynchronous with a fixed speed, and this speed is 
defined in the line definition: 

• /BZLNSPD - line speed. 



The following check is mandatory for line configuration: 
• /BZOWNER - owning host for this line. 

TABLE 14-3. TCB FIELD DESCRIPTOR TABLE 



FN 


Field 


Comments 


5 


BSTCIASS 


Terminal class. A new class must be defined if the terminal does 
not use a protocol identical to a current terminal (exceptions - 
minor variations are available by use of IVT command parameters). 


12 


BSOWNER 


Node ID of CS in the host. 


13 


BSCN 


Connection Number defined by initialization for this terminal. 


14 


BSLLCB (upper) 


The destination node (DN) byte in the LLCB that is used as a 
directory. 


15 


BSLLCB (lower) 


The source node (SN) byte in the liCB that is used as a directory. 


16 


BSABL 


Available block limit - the number of blocks that can be used by a 
TIP before triggering regulation if the TIP requests PTREGL to set 
regulation on available block count. 


19 


BSIPRI 


Input priority. The priority of an input block that will be 
accepted without triggering regulation if the TIP requests PTREGL 
to set regulation on input priority. 


28 


BSPGWIDTH 


Default page width (in characters) for the device. See note 1. 


29 


BSPGLENGTH 


Default page length (in lines) for the device. See note 1. 


30 


BSCANCHAR 


Character used to cancel an input line from the terminal. See 
note 2. 


31 


BSBSCHAR 


Character used for backspacing on the device. See note 2. 


32 


BSCNTRLCHAR 


Control character for the device. See note 2. 


33 


BSCRIDLES 


Carriage return idle count for the device. See note 2. 


34 


BSLFIDLES 


Line feed idle count for the device. See note 2. 


35 


BSCRCALC 


Flag to calculate the CR idle count for the device. 


36 


BSLFCALC 


Flag to calculate the LF idle count for the device. 


37 


BSAPL 


APL mode flag. See note 2. 


38 


BSXPARENT 


Transparent text delimiting flag. 


39 


BSXCHM 


Most significant 4 bits of the transparent character count 
(BSXCNT). See note 3. 


40 


BSXCHL 


Least significant 8 bits of the transparent character count 
(BSXCNT). See note 3. 


41 


BSXCHAR 


Transparent text delimiting character. See note 3. 


42 


BSXTO 


Transparent message delimited by timeout flag. Value is 300 + 100 
ms . See note 3. 
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TABLE 14-3. TCB FIELD DESCRIPTOR TABLE (2 of 2) 



FN 



43 



Field 



BSINDEV 



Comments 



Input device. See note 2. 



44 



BSOUTDEV 



Output device. See note 2. 



45 



BSECHOPLX 



Echoplex mode flag. See note 2. 



46 



47 



BSPGWAIT 



BSPARITY 



Page Wait Mode flag. See note 2. 



Parity type selector. 



48 



BSABTLINE 



Abort output line character. See note 2. 



49 



50 



BSUSRl 



BSUSR2 



User break character 1. See note 2. 



User break character 2. See note 2. 



51 



52 



BSCODE 



BSXCHRON 



TIP code set. Not used if autorecognition is used. See TIP type 
table in appendix E of SPRM. See note 4. 



Transparent message delimited by a delimiter character. See note 
3. 



NOTES: 

1. For interactive devices, this value can be altered later by an IVT command. A message is sent 
upline changing this value in CS, but not in the load file. At reload time, the value reverts to 
this initialization value. 

2. For interactive devices, this value can be altered later by an IVT command. The value is kept 
locally in the TCB. Any action that causes release of the TCB loses the changed value. 
Reconfiguration of the TCB from the host uses the initialization value. 

3. For interactive devices, the character count, timeout flag or transparent delimiting character in 
the TCB INT overlay can be changed by an upline IVT parameter change message from the interactive 
device. All of the values revert to default value after the current transparent message is 
processed. 

4. New codes will need to be defined for new TIP that services a multi-code terminal group. 



Figure 14-6 shows a sample of the LCB action table 
initialization statements. 

The MPEDIT statements for LCB action table ini- 
tialization are included in the user supplied COMDECK 
ZEXtip. 



STATE PROGRAM ADDRESS LINKAGE 

A TIP can be written with various state programs and 
code conversion tables used dynamically, depending on the 
situation at the terminal. If this is done, the TIP writer 
must initialize globals with addresses, so the PASCAL 
code can reference the content. 



*********************************** 

* * 

* USER TIP 1 LCB ACTION TABLE * 

* * 



UALIAT 1 .DFFN := /BZOWHER; 

UALIAT 1 .DFRKEY := D2VL; 

UALIAT 1 .DFCKEY := D2VL; 

UALIAT 1 .DFPARAM := 1: 

UALIAT 2 .DFFN := /BZLNSPO; 

UALIAT 2 .DFRKEY := D2VU; 

UALIAT 2 .DFCKEY := D2VH; 

UALIAT 2 .DFPARAM := 8: 



UALIAT 3 .OFEND 



$7FFF; 



END OF TABLE 



Figure 14-6. MPEDIT Initialization Statements for LCB 
Action Table (Sample) 
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BLOCK PROTOCOL ACKNOWLEDGMENT SCHEME 



The nine block types plus four special commands (block 
type 4) are used to establish and maintain communication 
between the host and the NPU. Tables A-1 and A-2 show 
the block acknowledgment scheme. In general, the fol- 
lowing applies: 

• BACK blocks are never acknowledged 

• MSG and BLK blocks are always BACKed 

■ CMD blocks to a TIP (CN^O) are BACKed 

■ CMD blocks (service messages) downline are 
acknowledged by an upline service message reply 

■ BRK blocks downline cause an RST block to be 
sent upline 



BRK upline causes host to notify the application 
program which sent the MSG, BLK, or CMD 
block. Sender decides whether to retransmit block 

INIT, RST, and STP downline are not acknowledged 

STRT downline causes an RST block to be sent 
upline. 

STP block upline is not acknowledged 

INIT upline causes an INIT downline 

STRT block upline causes an RST downline 



TABLE A-1. NPU ACKNOWLEDGMENT OF DOWNLINE BLOCKS 



Block Type 


Queued To 


Acknowledged By 


Remarks 


BACK 


Not queued 


Not acknowledged 


BIP decrements outstanding block count and 
releases the BACK block. 


Bad block 


Not queued 


Not acknowledged 


BIP counts this as a bad address input block and 
discards. 


CMD with 
CN=0 


SVM 


Service module 
with a reply SM 


Response service message is the acknowledgment. 


CMD with 
CNr'O 


TCB's output queue 


TIP (may be thru 
PTiVTCMD) with a 
BACK block 


If application to TIP CMD, TIP calls PTBACK. 
TIP also generates input stopped CMD block 
messages. If downline IVT CMD block, PTIVTCMD 
sends BACK block if parameters successfully 
changed, otherwise, BRK block is sent. BRK 
block is sent for any unintelligible CMD block 
received by TIP. 


MSG/ BLK 


TCB's output queue 


BIP 


TIP calls BIP when message is transmitted to 
terminal, BIP sends BACK. 


BRK 


TIP WLE to OPS-level 


BIP RST block 


BIP sends a RST block; sends WLE to TIP (allows 
higher priority than data). 


INIT 


Not queued 


Not acknowl edged 


Processed by BIP which sets accept input (AI) 
and accept output (AO) flags. BIP also sets 
outstanding block limit (OBL) counter to 0. 


RST 


Not queued 


Not acknowledged 


Processed by BIP which sets accept output (AO) 
flag. 


STRT 


Not queued 


BIP with RST block 


BIP sets accept input (AI) flag and sends the 
reset block. 


STOP 


TIP WLE to OPS-level 


Hot acknowledged 


BIP clears accept input (AI) flag. However, WLE 
allows processing the communications line of 
messages with higher priority than data. 
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TABLE A-2. ACKNOWLEDGMENT OF TIP-GENERATED UPLINE BLOCKS 



Block Types 


Acknowledgment Required 


Remarks 


BACK 


No 


BACK block is acknowledgment to previous MSG, CMD or BLK 
block sent to host. 


CMD CN=0 


No 


This is either an unsolicited SM that requires 
specifications from host or is the solicited answer to 
host's previous SM to the NPU (SVM processes). 
Unsolicited SMs are repeated after a time interval until 
the required action from the host is detected. 


CMD CNjtO 


Yes 


Host responds with a BACK block. 


BRK 


Yes 


Host responds with a RST. MSG/BLK/CMD blocks not 
acknowledged may be repeated. 


BLK or MSG 


Yes, BACK block 


Internal BID process handles the BACK block. TIP is not 
notified. 


STRT 


Yes 


Host replies with RST to start output. 


STP 


No 


Accept output flag is reset. TCB's output data queue is 
purged. 
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